https on Fedora give input/output error

[GoogleCodeExporter]

May be related to Issue #125

Using option url=https://s3.amazonaws.com on Fedora causes an
input/output error (i.e. it doesn't work).

curl error code 51 is logged in /var/log/messages
Nov 25 20:34:04 fedora s3fs: ###curlCode: 51  msg: SSL peer certificate or SSH 
remote key was not OK

Here's the definition of this in the curl documentation:

CURLE_PEER_FAILED_VERIFICATION (51)
The remote server's SSL certificate or SSH md5 fingerprint was deemed not OK. 

Looks like curl is current:

% curl --version
curl 7.21.0 (x86_64-redhat-linux-gnu) libcurl/7.21.0 NSS/3.12.7.0 zlib/1.2.5 
libidn/1.18 libssh2/1.2.4
Protocols: dict file ftp ftps http https imap imaps ldap ldaps pop3 pop3s rtsp 
scp sftp smtp smtps telnet tftp 
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz 

$ curl-config --ca
/etc/pki/tls/certs/ca-bundle.crt

Original issue reported on code.google.com by dmoore4...@gmail.com on 26 Nov 2010 at 4:08

[GoogleCodeExporter]

Aha! ...it's not related to 125 (the certificate file was found just fine), but 
is a different issue all together. 

Turning on curl debugging reveals this:

curl_easy_setopt(curl, CURLOPT_VERBOSE, true);

* About to connect() to s3.amazonaws.com port 443 (#0)
*   Trying 207.171.191.241... * connected
* Connected to s3.amazonaws.com (207.171.191.241) port 443 (#0)
* Initializing NSS with certpath: /etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using SSL_RSA_WITH_RC4_128_MD5
* Server certificate:
*   subject: CN=s3.amazonaws.com,O=Amazon.com Inc.,L=Seattle,ST=Washington,C=US
*   start date: Dec 18 00:00:00 2009 GMT
*   expire date: Dec 18 23:59:59 2010 GMT
*   common name: s3.amazonaws.com
*   issuer: CN=VeriSign Class 3 Secure Server CA - G2,OU=Terms of use at 
https://www.verisign.com/rpa (c)09,OU=VeriSign Trust Network,O="VeriSign, 
Inc.",C=US
> GET / HTTP/1.1
Host: s3.amazonaws.com
Accept: */*
Date: Fri, 26 Nov 2010 04:46:39 GMT
Authorization: AWS XXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXX 

< HTTP/1.1 200 OK
< x-amz-id-2: xjMutXq8s8S3pYduiqv9Wa2s1WPa7ctWy/hdKnw1pybne80Juk94v6ghpgzNpFBy
< x-amz-request-id: 65A389ED355B20DA
< Date: Fri, 26 Nov 2010 04:46:41 GMT
< Content-Type: application/xml
< Transfer-Encoding: chunked
< Server: AmazonS3
< 
* Connection #0 to host s3.amazonaws.com left intact

* About to connect() to misc.suncup.org.s3.amazonaws.com port 443 (#1)
*   Trying 207.171.183.117... * connected
* Connected to misc.suncup.org.s3.amazonaws.com (207.171.183.117) port 443 (#1)
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL: certificate subject name '*.s3.amazonaws.com' does not match target host 
name 'misc.suncup.org.s3.amazonaws.com'
* NSS error -12276
* Closing connection #1
* SSL peer certificate or SSH remote key was not OK

s3fs: my_curl_easy_perform: curlCode: 51 -- SSL peer certificate or SSH remote 
key was not OK

So it looks like the virtual hosted-style method (as opposed to the older 
path-style method) has an issue with secure connections. Most likely, this is a 
function of a newer version of curl. ???

Amazon has to support this, so there may be a way to get curl to ignore this.

It also looks like the "check service" routine could be a bit more robust as it 
doesn't catch this error. That's because the host is s3.amazon.com vs. a 
virtual host.  

Original comment by dmoore4...@gmail.com on 26 Nov 2010 at 5:00

[GoogleCodeExporter]

As it turns out this is a known limitation of bucket names with periods and 
using SSL:

http://docs.amazonwebservices.com/AmazonS3/latest/dev/

   "When using virtual hosted-style buckets with SSL, the SSL wild card certificate only matches buckets that do not contain periods. To work around this, use HTTP or write your own certificate verification logic."

curl has an option to allow for ignoring the host name matching: 
CURLOPT_SSL_VERIFYHOST  yet still verify the certificate.

The easy solution is to use this option whenever a host name with periods is 
used AND we are using SSL.

The "right" solution would be as the Developer Guide suggest, is to do the 
pattern matching ourselves.

I'm not sure how important this may be to our users as this does present a 
security hole in this corner case.  Rather than let the security hole go 
unnoticed, it might be prudent to provide an option to allow the user to turn 
off the check if they must use a bucket with periods and SSL.  ...thoughts?

Original comment by dmoore4...@gmail.com on 26 Nov 2010 at 6:28

[GoogleCodeExporter]

I have confirmed that this is due to how curl is compiled in the different 
distros.  In Fedora, curl is compiled with  --without-openssl & --with-nss, 
whereas Ubuntu uses openssl

Underneath, openssl and nss does the hostname checking differently. I'm not 
entirely sure how it is different, but it acts differently as shown below:

Ubunutu:

* Connection #0 to host s3.amazonaws.com left intact
* About to connect() to misc.suncup.org.s3.amazonaws.com port 443 (#1)
*   Trying 72.21.207.153... * connected
* Connected to misc.suncup.org.s3.amazonaws.com (72.21.207.153) port 443 (#1)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSL connection using RC4-MD5
* Server certificate:
*    subject: C=US; ST=Washington; L=Seattle; O=Amazon.com, Inc.; 
CN=*.s3.amazonaws.com
*    start date: 2010-01-12 00:00:00 GMT
*    expire date: 2011-03-29 23:59:59 GMT
*    subjectAltName: misc.suncup.org.s3.amazonaws.com matched
*    issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert High 
Assurance CA-3
*    SSL certificate verify ok.

Fedora:

* Connection #0 to host s3.amazonaws.com left intact
* About to connect() to misc.suncup.org.s3.amazonaws.com port 443 (#1)
*   Trying 72.21.207.153... * connected
* Connected to misc.suncup.org.s3.amazonaws.com (72.21.207.153) port 443 (#1)
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL: certificate subject name '*.s3.amazonaws.com' does not match target host 
name 'misc.suncup.org.s3.amazonaws.com'
* NSS error -12276
* Closing connection #1
* SSL peer certificate or SSH remote key was not OK

If I understood it correctly, openssl is doing a pattern match and nss is doing 
a DNS match.  Apparently, nss is more secure and conforms to the limitation 
that AWS developers guide outlines above.

So this isn't a "bug" per se, it's just that openssl is a bit lax in this area.

Here's what I'm going to do:

  - If this error occurs, I'm going to trap it and exit s3fs notifying the user of the limitation and giving the user the option to over-ride this check.

This should be transparent to users in which their OS's libcurl was compiled 
with openssl.

Original comment by dmoore4...@gmail.com on 26 Nov 2010 at 7:55

[GoogleCodeExporter]

This issue was closed by revision r270.

Original comment by dmoore4...@gmail.com on 26 Nov 2010 at 10:11

• Changed state: Fixed