Bug 784719

Summary: Can't access certain hosts with SSL
Product: [Fedora] Fedora Reporter: Felipe Contreras <felipe.contreras>
Component: nssAssignee: Elio Maldonado Batiz <emaldona>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 16CC: emaldona, kdudka, kengert
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-01-26 10:42:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Felipe Contreras 2012-01-25 22:26:16 UTC
Description of problem:
SSL doesn't work on certain hosts. It works perfectly fine on other machines (Windows, Arch Linux, etc.)

Version-Release number of selected component (if applicable):
nss-3.13.1-10

Steps to Reproduce:
1. curl --verbose 'https://access.nokia.com'
  
Actual results:
curl: (35) SSL connect error

Expected results:
It works

Same with any other browser.

Comment 1 Kai Engert (:kaie) (inactive account) 2012-01-25 22:48:33 UTC
I'm on latest F16 and same NSS version, but cannot reproduce your problem.

Are you it's not a Firewall issue, i.e. maybe your browser has a proxy configured that curl doesn't know about?

In a terminal, try
  telnet access.nokia.com 443

Do you get a message saying "connected"?

Comment 2 Felipe Contreras 2012-01-25 22:56:53 UTC
(In reply to comment #1)
> I'm on latest F16 and same NSS version, but cannot reproduce your problem.
> 
> Are you it's not a Firewall issue, i.e. maybe your browser has a proxy
> configured that curl doesn't know about?

No. I'm firing the same curl command on Arch Linux, and it works fine. Plus, the F16 box is sharing the connection to the Arch Linux box, so if it was a firewall issue the problem would be propagated.

> In a terminal, try
>   telnet access.nokia.com 443
> 
> Do you get a message saying "connected"?

Yes.

I can also see from wireshark that the client hello is being sent (with curl), but in F16 it's SSL, and on Arch Linux it's TLSv1.

Comment 3 Kamil Dudka 2012-01-26 00:14:10 UTC
Please try the options --sslv3/--tlsv1 of curl and attach the full output of curl --verbose.

Comment 4 Felipe Contreras 2012-01-26 00:49:08 UTC
(In reply to comment #3)
> Please try the options --sslv3/--tlsv1 of curl and attach the full output of
> curl --verbose.

Already tried that, doesn't help:

% curl --verbose -1 -k --ciphers rsa_3des_sha 'https://access.nokia.com' 
* About to connect() to access.nokia.com port 443 (#0)
*   Trying 192.100.106.44... connected
* Connected to access.nokia.com (192.100.106.44) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* warning: ignoring value of ssl.verifyhost
* NSS error -5990
* Closing connection #0
* SSL connect error
curl: (35) SSL connect error

% curl --verbose -3 -k --ciphers rsa_3des_sha 'https://access.nokia.com'
* About to connect() to access.nokia.com port 443 (#0)
*   Trying 192.100.106.44... connected
* Connected to access.nokia.com (192.100.106.44) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* warning: ignoring value of ssl.verifyhost
* NSS error -5990
* Closing connection #0
* SSL connect error
curl: (35) SSL connect error

And yes, I tried exactly the same command in Arch Linux and it works (I had to compile curl with NSS).

Comment 5 Felipe Contreras 2012-01-26 01:42:34 UTC
I compiled curl with OpenSSL and I still had the same problem, which didn't make any sense... What could cause both OpenSSL and NSS to fail, but apparently only with some hosts?

Then I remembered that some time ago I enabled this 'net.ipv4.tcp_ecn', as bufferfloat.org. Disabling it makes things work again.

Comment 6 Kamil Dudka 2012-01-26 10:42:55 UTC
Thank you for clarifying it.  There is most likely some problem on the network between you and the host.  I do not think this is something we can fix in curl or nss.  I am closing this out.

Comment 7 Felipe Contreras 2012-01-26 13:04:33 UTC
(In reply to comment #6)
> Thank you for clarifying it.  There is most likely some problem on the network
> between you and the host.  I do not think this is something we can fix in curl
> or nss.  I am closing this out.

Yes, most likely there's a problem with the hosts's implementation of TCP/IP, or something like that.

Comment 8 Kai Engert (:kaie) (inactive account) 2012-01-26 14:32:14 UTC
Your error output mentions NSS error -5990.

mozilla/nsprpub/pr/include/prerr.h:
   78 : #define PR_IO_TIMEOUT_ERROR                      (-5990L)

This means, curl gets a timeout error, it cannot even connect to the destination host:port.

I don't understand why your configuration failed with NSS, failed with openssl, but worked with plain telnet. If that's a kernel configuration, you shouldn't have gotten a connection with telnet either, right?

Comment 9 Kamil Dudka 2012-01-26 15:08:00 UTC
(In reply to comment #8)
> This means, curl gets a timeout error, it cannot even connect to the
> destination host:port.

Nope, the error code comes from the SSL handshake.  libcurl connects to the remote host using the API for POSIX sockets, then it asks NSS to do the SSL handshake on the already connected socket.

> % curl --verbose -1 -k --ciphers rsa_3des_sha 'https://access.nokia.com' 
> * About to connect() to access.nokia.com port 443 (#0)
> *   Trying 192.100.106.44... connected
> * Connected to access.nokia.com (192.100.106.44) port 443 (#0)

This ^^^ means that connect() already succeeded.

> * Initializing NSS with certpath: sql:/etc/pki/nssdb
> * warning: ignoring value of ssl.verifyhost
> * NSS error -5990
> * Closing connection #0
> * SSL connect error
> curl: (35) SSL connect error

This ^^^ comes from NSS.  Translation of NSS error -5990 to a human-readable string is on my TOOD list though.

> I don't understand why your configuration failed with NSS, failed with openssl,
> but worked with plain telnet. If that's a kernel configuration, you shouldn't
> have gotten a connection with telnet either, right?

The issue is kind of reproducible on my box:

# echo 1 > /proc/sys/net/ipv4/tcp_ecn

# telnet access.nokia.com 443
Trying 192.100.130.18...
Connected to access.nokia.com.
Escape character is '^]'.
Connection closed by foreign host.

# curl --verbose -1 -k --ciphers rsa_3des_sha 'https://access.nokia.com'
* About to connect() to access.nokia.com port 443 (#0)
*   Trying 192.100.130.18...
* connected
* Connected to access.nokia.com (192.100.130.18) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* warning: ignoring value of ssl.verifyhost

It keeps hanging at this ^^^ step...