curl -v https://www.paypal.com [...] * Server certificate: * subject: 1.3.6.1.4.1.311.60.2.1.3=US; 1.3.6.1.4.1.311.60.2.1.2=Delaware; businessCategory=Private Organization; serialNumber=3014267; C=US; postalCode=95131-2021; ST=California; L=San Jose; street=2211 N 1st St; O=PayPal, Inc.; OU=PayPal Production; CN=www.paypal. * start date: 2011-03-23 00:00:00 GMT * expire date: 2013-04-01 23:59:59 GMT * common name: www.paypal.com (matched) * issuer: C=US; O=VeriSign, Inc.; OU=VeriSign Trust Network; OU=Terms of use at https://www.verisign.com/rpa (c)06; CN=VeriSign Class 3 Extended Validation SSL CA * SSL certificate verify ok. [...] CN=www.paypal. what's wrong with curl? I asked my friend who runs Gentoo and he has the same problem. I tested curl on RHEL5.6, this problem doesn't exits. Please check and mark this confirmed, or if you cannot reproduce, mark it invalid :-( Reproducible: Always
Created attachment 314257 [details] emerge --info
Please post your output for `emerge --info net-misc/curl' in a comment.
My guess is that it just cuts off the subject at a fixed number of characters.
(In reply to comment #2) > Please post your output for `emerge --info net-misc/curl' in a comment. Maybe plain `emerge --info' is enough, as CURL_SSL is unset.
(In reply to comment #4) > (In reply to comment #2) > > Please post your output for `emerge --info net-misc/curl' in a comment. > > Maybe plain `emerge --info' is enough, as CURL_SSL is unset. This happens with CURL_SSL="openssl". It happens on all versions of curl on the tree, ie back to curl-7.21.4, and it only happens with www.paypal.com as far as I can tell. 1. I suspected openssl (see bug #403619), however, it is probably not: openssl s_client -connect www.paypal.com:443 ... snip ... subject=/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/businessCategory=Private Organization/serialNumber=3014267/C=US/postalCode=95131-2021/ST=California/L=San Jose/street=2211 N 1st St/O=PayPal, Inc./OU=PayPal Production/CN=www.paypal.com ... snip ... The full CN is visible. Since the openssl client links against the same opnessl libraries, looks like curl at least has access to the full "subject..." string. 2. If I try curl -v https://www.mtgox.com, I get * subject: description=402815-Iee616oLVjl1h4ZF; C=JP; ST=Tokyo; L=Kugayama; O=Tibanne Ltd.; OU=StartCom Verified Certificate Member; CN=www.mtgox.com; emailAddress=contact@tibanne.com 3. Or a server I run curl -v https://ddl.dyc.edu: * subject: C=US; ST=New York; L=Buffalo; O=D'Youville College; OU=Distance Learning; OU=Terms of use at www.verisign.com/rpa (c)05; CN=ddl.dyc.edu Note: the string length "subject: ... CN=www.paypal." is longer for paypal than for either mtgox.com or ddl.dyc.edu. 4. I don't have access to Red Hat 5.6, but if the reporter can give me more details, or knows if this is/is not an issue on a Centos box or can give me more clues so I can compare gentoo's curl with redhat's, it might help before I dive into the code and try to fid
(In reply to comment #5) > 4. I don't have access to Red Hat 5.6, but if the reporter can give me more > details, or knows if this is/is not an issue on a Centos box or can give me > more clues so I can compare gentoo's curl with redhat's, it might help > before I dive into the code and try to fid Hi Anthony, this is the SRPM package of the curl I tested on RHEL 5.6 http://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/curl-7.15.5-9.el5.src.rpm
Here's a test from Ubuntu with curl 7.19.7-1ubuntu1.1 * Server certificate: * subject: 1.3.6.1.4.1.311.60.2.1.3=US; 1.3.6.1.4.1.311.60.2.1.2=Delaware; 2.5.4.15=Private Organization; serialNumber=3014267; C=US; postalCode=95131-2021; ST=California; L=San Jose; streetAddress=2211 N 1st St; O=PayPal, Inc.; OU=PayPal Production; CN=www.paypal.c The output of curl-7.25.0 from gentoo-prefix I installed on the same server has the same as my Gentoo Linux on my laptop ( CN=www.paypal. )
The reason for this bug is obvious after reading some source code. See this: https://github.com/bagder/curl/blob/master/lib/ssluse.c#L2276 rc = x509_name_oneline(X509_get_subject_name(connssl->server_cert), buffer, sizeof(buffer)); As you can see, the subject name is put into a buffer of 256 chars long, and thus long strings are chunked. The commit causing this bug is at https://github.com/bagder/curl/commit/4c9768565ec3a9baf26ac8a547bca6e42cc64fa5#L11L1652 The original implement is str = X509_NAME_oneline(X509_get_subject_name(connssl->server_cert), NULL, 0); This will cause X509_NAME_oneline() alloc a buffer itself, and should work fine. I don't know it's a bug or by design, perhaps there is a security concern?
(In reply to comment #8) > I don't know it's a bug or by design, perhaps there is a security concern? Thanks for doing the leg work on this. Looks like this is by design to me, but we can bounce it off upstream.
Okay reported upstream. Let's see what they have to say.
Okay this one is fixed upstream. ./curl --version curl 7.27.0-20120617 (x86_64-unknown-linux-gnu) libcurl/7.27.0-20120617 OpenSSL/1.0.0j zlib/1.2.5.1 libssh2/1.4.0 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp Features: IPv6 Largefile NTLM NTLM_WB SSL libz ./curl -v https://www.paypal.com * subject: 1.3.6.1.4.1.311.60.2.1.3=US; 1.3.6.1.4.1.311.60.2.1.2=Delaware; businessCategory=Private Organization; serialNumber=3014267; C=US; postalCode=95131-2021; ST=California; L=San Jose; street=2211 N 1st St; O=PayPal, Inc.; OU=PayPal Production; CN=www.paypal.com The fix will be out in the next release and since this is not leading to serious failure we can wait. Reopen if you think this has to be fixed immediately.
