Igor Zhbanov | 22 Nov 16:51 2014
Picon

error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

Hi!

I have upgraded my server to OpenSuSE-13.2 and got following error:

$ curl -v https://www.whatwg.org/

* Hostname was NOT found in DNS cache
*   Trying 208.113.236.128...
* Connected to www.whatwg.org (208.113.236.128) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs/
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS alert, Server hello (2):
* error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert
handshake failure
* Closing connection 0
curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure

Is this problem with web-site's settings or with curl cyphers options?

$ curl --version

curl 7.38.0 (x86_64-suse-linux-gnu) libcurl/7.38.0 OpenSSL/1.0.1j
zlib/1.2.8 libidn/1.28 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API SPNEGO NTLM NTLM_WB SSL
libz TLS-SRP
(Continue reading)

Ingimar | 20 Nov 15:36 2014
Picon

curl post

Hi!

I am trying to post an array-list to a restful-service which I created.
I am able doing this by using JSON, my method is annotated :  <at> Consumes(MediaType.APPLICATION_JSON) 

as in:
 curl -i -X POST -H 'Content-Type: application/json' -d '{"list":["key1:val1","key2:val2"]}' http://localhost:8080/MediaServerResteasy/media/testing

I would like to be able to post from a HTML-FORM.
I changes the annotation on my restful to :
<at> Consumes(MediaType.MULTIPART_FORM_DATA)

Check out the following:

did try the following :
curl -X POST -H "Content-Type:multipart/form-data" -F 'taglist[]=key1:value1' -F 'taglist[]=key2:value2'  http://localhost:8080/MediaServerResteasy/media/testing

curl -X POST -H "Content-Type:multipart/form-data" -F 'taglist=key1:value1' -F 'taglist=key2:value2'  http://localhost:8080/MediaServerResteasy/media/testing

but neither is working.
What am I doing wrong here ?

My Java-form looks like this:
<at> FormParam("taglist")
    private List<String> taglist;

    public List<String> getTaglist() {
        return taglist;
    }

    
    public void setTaglist(List<String> taglist) {
        this.taglist = taglist;
    }

Regards, i
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Charles Pritchard | 20 Nov 02:30 2014

Sending an unbuffered PUT without chunked encoding

How would I signal to CURL that I want to PUT data from STDIN without using chunked encoding and without buffering?

Currently, -T triggers chunked encoding, I don't want that.

I already know the content length ahead of time, so I don't need curl buffering the full data into memory as it does with --data-binary <at> -.

-Charles
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Rayston | 17 Nov 22:07 2014
Picon

socket connection, waiting for ENQ

Is there a way from the curl command line tool to open a connection, wait for an ENQ response and then send data in a file?
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Jemiolo, John | 6 Nov 17:10 2014
Picon

curl ipv6 command line questions

I have been trying to sort out communicating with a system on a private network from a SLES11 SP3 Linux host using: curl 7.38
 
What I have found was
 
curl  -x “”   --interface eth1  http://<IPv4 Address>/path    ß works for IPv4
 
curl  -x “” http://[IPv6 Address%25eth1]/path   ßworks for IPv6
 
curl  -x “”   --interface eth1  http://[IPv6 Address]/path  ßDOES NOT WORK for IPV6  seems to just hang forever.
 
Now why “%25eth1”  works I do not know, I cannot find this usage in any of the curl doc’s  (I tried this because I use this ssh’ing to ipv6 hosts.
 
Also why does “ –interface  eth1  “ work for IPv4  and not IPv6?
 
Also the “–g” option,   its use seems not to have any effect when using IPv6 addresses, what is its correct usage?
 
Am I missing something?
 
JJ
 
 
 
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html
narkedimilly navya | 6 Nov 10:00 2014
Picon

Extra colon is observed while downloading certificates from LDAP using CURL 7.37 version.

Hi All,

We are getting extra colon while downloading the certificates from LDAP using CURL 7.37 where as we didn`t see this "::" with old
version of curl (7.37).
can you please suggest why is this change present between the CURL 7.35 and CURL 7.37 versions.

while using curl 7.35 version :
rpm -qa | grep curl
libcurl-7.19.7-35.el6.x86_64
 
curl -k -o /tmp/rootca.pem --url "ldap://<ip/port>/dc=generic,dc=com?cACertificate?sub?(CN=Generic_Root_CA)" -m 60
[root <at> BLR7INST3-nib-9 ~]# cat /tmp/rootca.pem
DN: CN=Generic_Root_CA,O=Generic,dc=generic,dc=com
cACertificate;binary:
 
while using Curl 7.37 version :

rpm -qa | grep curl
curl-7.37.1-7.37.1.noarch
curl -k -o /tmp/rootca.pem --url "ldap://<ip/port>/dc=generic,dc=com?cACertificate?sub?(CN=Generic_Root_CA)" -m 60
[root <at> BLR7INST1-nib-1 ~]# cat /tmp/rootca.pem | grep binary
cACertificate;binary::

Thanks
Navya.
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Daniel Stenberg | 5 Nov 08:58 2014
Picon

[SECURITY ADVISORY] libcurl duphandle read out of bounds

libcurl duphandle read out of bounds
====================================

Project cURL Security Advisory, November 5th 2014 -
[Permalink](http://curl.haxx.se/docs/adv_20141105.html)

VULNERABILITY
-------------

libcurl's function
[`curl_easy_duphandle()`](http://curl.haxx.se/libcurl/c/curl_easy_duphandle.html)
has a bug that can lead to libcurl eventually sending off sensitive data that
was not intended for sending.

When doing an HTTP POST transfer with libcurl, you can use the 
`CURLOPT_COPYPOSTFIELDS` option to specify a memory area holding the data to 
send to the remote server. The memory area's size is set with a separate 
option, for example `CURLOPT_POSTFIELDSIZE`.

As the name implies, the data in the specified buffer is copied to a privately 
held memory buffer that libcurl allocates on the heap. The memory area is 
associated with the common CURL handle, often referred to as an "easy handle".

This handle can be duplicated by an application to create an identical copy, 
and all the already set options and data is then also similarly cloned and 
will be associated with the newly returned handle. This also includes the data 
to send in an HTTP POST request.

The internal libcurl function that duplicates options from the old handle to
the new had two problems:

1. It mistakenly treated the post data buffer as if it was a C string which is
    assumed to end with a zero byte. strdup() was subsequently used to
    duplicate the post data buffer, and as a post data buffer can both
    legitimately contain a zero byte, or may not contain any zero bytes at all
    (including a tailing one), strdup() could create a copy that a) was too
    small b) was too large or c) could crash due to reading an inaccessible
    memory area. The strdup() function of course allocates memory off the heap.

2. After duplication of the handle data, the pointer used to read from when
    sending the data was not updated. So when sending off the post, libcurl
    would still read from the original handle's buffer which at that time could
    have been freed or reused for other purposes.

When libcurl subsequently constructs the HTTP POST request and includes data
for the protocol body it will memcpy() data from that pointer using the old
size and the old pointer. This makes a read from the wrong place and can lead
to libcurl inserting data into the request that happens to be stored at that
places in memory at that time.

We are not aware of anyone having been able to actually exploit this for
nefarious purposes, but we can't exclude that it is possible or even might
already have been exploited.

INFO
----

This bug requires `CURLOPT_COPYPOSTFIELDS` and `curl_easy_duphandle()` to be
used in that order, and then the duplicate handle must be used to perform the
HTTP POST.

The curl tool is not affected, it does not use this sequence.

The Common Vulnerabilities and Exposures (CVE) project has assigned the name
CVE-2014-3707 to this issue.

AFFECTED VERSIONS
-----------------

This bug has existed since `CURLOPT_COPYPOSTFIELDS` was introduced.

- Affected versions: from libcurl 7.17.1 to and including 7.38.0
- Not affected versions: libcurl >= 7.39.0

libcurl is used by many applications, but not always advertised as such!

THE SOLUTION
------------

libcurl 7.39.0 makes sure that the buffer area is duplicated and presumed to
be binary.

A patch for this problem is available at:

     http://curl.haxx.se/CVE-2014-3707.patch

RECOMMENDATIONS
---------------

We suggest you take one of the following actions immediately, in order of
preference:

A - Upgrade to curl and libcurl 7.39.0

B - Apply the patch and rebuild libcurl

C - Avoid using `CURLOPT_COPYPOSTFIELDS` then `curl_easy_duphandle()`

If you are using PHP/CURL, we advice you to avoid `curl_copy_handle()` after
`CURLOPT_POSTFIELDS`, since PHP then uses `CURLOPT_COPYPOSTFIELDS` "under the
hood".

TIME LINE
---------

It was first reported to the curl project on September 16th 2014.

We contacted distros <at> openwall on October 20.

libcurl 7.39.0 was released on November 5th 2014, coordinated with the
publication of this advisory.

CREDITS
-------

Reported by Symeon Paraschoudis. Stas Malyshev helped us understand and repeat
the problem. Dan Fandrich helped assess the security risk. Tomas Hoger
analyzed the second part of the bug. Patch written by Daniel Stenberg.

Thanks a lot!

--

-- 

  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html
George | 4 Nov 17:06 2014
Picon

curl not using tls even if told to do so

Hi,

I am trying to connect to a remote host using curl. The remote host
supports only tlsv1.2 and the RC4-SHA cipher. It does not support NSS,
only OpenSSL.

The default curl that comes with CentOS 7(the one I am using) was
using NSS so that didn't work for me.

Now I got the latest curl from git and manually compiled it with
support of openssl and without nss. My curl -V output is:
curl 7.38.1-DEV (x86_64-unknown-linux-gnu) libcurl/7.38.1-DEV
OpenSSL/1.0.1e zlib/1.2.7 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s
rtsp scp sftp smtp smtps telnet tftp
Features: IPv6 Largefile NTLM NTLM_WB SSL libz

I am running curl like this:
/usr/local/bin/curl -v --tlsv1.2 --cipher RC4-SHA --key ./somekey.pem
--cert ./somecert.crt https://somedomain.com/somepath

But the strange thing is that from the verbose output I can see that
curl is still trying to connect with SSLv3 which is not available:
* Hostname was NOT found in DNS cache
*   Trying 1.1.1.1...
* Connected to somedomain.com (1.1.1.1) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Request CERT (13):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS handshake, CERT verify (15):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS alert, Server hello (2):
* error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
* Closing connection 0
curl: (35) error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert
handshake failure

So why does curl refuse to use tlsv1.2 even if told to do so?

Please help
Thanks
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html
John Goebel | 3 Nov 20:43 2014

Building cURL passing the -R option to linker

On Ubuntu 10.04 (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1)) passing 
the -R option using LDFLAGS works.
CPPFLAGS="-I/opt/openssl/include" LDFLAGS="-L/opt/openssl/lib" 
LDFLAGS="-R/opt/openssl/lib" ./configure --with-ssl=/opt/openssl 
--prefix=/opt/curl
gcc 4.4.3 reported "unrecognized option '-R/opt/openssl/lib'" but continued.

On Ubuntu 12.04 (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)) 
configure failed with error "configure: error: C compiler cannot create 
executables".
gcc 4.6.3 reported "gcc: error: unrecognized option '-R'" and then 
terminated. configure failed with " C compiler cannot create executables".

The solution is to not pass 'LDFLAGS="-R/opt/openssl/lib"', replace it 
with '-Xlinker -rpath=/opt/openssl/lib"'.
CPPFLAGS="-I/opt/openssl/include" LDFLAGS="-L/opt/openssl/lib -Xlinker 
-rpath=/opt/openssl/lib" ./configure --with-ssl=/opt/openssl 
--prefix=/opt/curl

I don't know if this is an Ubuntu oddity, or if there is a better 
solution. In any even it worked for me, and perhaps should be added to 
the INSTALL file.

John Goebel
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Can a request from curl look as if it came from a browser?

Can curl send a request to a web server in a way that makes it impossible
for the web server to know that it's from curl, and not a user doing a
manual webpage request in a browser?

I mean, I presume there's some way to send the equivalent of a browser
id/agent string but is there anything more subtle that would tell a server
curl's involved?

--

-- 
Jeremy C B Nicoll - my opinions are my own.
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Picon

ECDSA certificate with curl

Hi,

I tried to use ECDHE-ECDSA-AES128-GCM-SHA256 cipher in the openssl using curl. But curl seems to be not liking ECDSA certificate for server identity when it tried to make https connection. The curl version is latest 7.38.0

Is there any fix for the curl to make it work with ECDSA certificates?

 

Regards,

Ram

 

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Gmane