Bug 784719 - Can't access certain hosts with SSL
Summary: Can't access certain hosts with SSL
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: nss
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Elio Maldonado Batiz
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-25 22:26 UTC by Felipe Contreras
Modified: 2012-01-26 15:08 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-26 10:42:55 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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...


Note You need to log in before you can comment on or make changes to this bug.