301006 - Error Code: -8187 (invalid args) connecting to openSSL server

Status: RESOLVED DUPLICATE of bug 107491

(Firefox :: Security, defect)

Description

[Ralf Hauser]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Shouldn't it say something like "the https server you are attempting to connect
to appears to be misconfigured - it does not accept any cipher acceptable to 
firefox. Click here for more info" and if one clicks, it would list the ciphers
firefox offers to servers.

How to reproduce: 

   openssl s_server -accept 443 -www -cipher EXPORT

and then connect your firefox to localhost.

Reproducible: Always

Comment 1

[Ralf Hauser]

with -debug on openssl, it appears that one can see the firefox offered
ciphers:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:RC4-MD5:RC4-SHA:AE
S128-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:EXP1
024-RC4-SHA:EXP1024-DES-CBC-SHA:EXP-RC4-MD5:EXP-RC2-CBC-MD5

If the server is started with 

  openssl s_server -accept 443 -cipher LOW

firefox appears to agree on
   EDH-RSA-DES-CBC-SHA
which as per
http://www.openssl.org/docs/apps/ciphers.html#SSL_v3_0_cipher_suites_ is only
single DES (TLS_DHE_RSA_WITH_DES_CBC_SHA)!

Should that also trigger at least a warning to the end-user?

Comment 2

[Matthias Versen [:Matti]]

*** This bug has been marked as a duplicate of 107491 ***

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

The original "summary" for this bug as:

provide a better error message if https server only offers export level ciphers
- currently "Error establishing encrypted connection to ... Error Code: -8187"

which is way too long, and probably a misdiagnosis.

If the error number being reported is really -8187 (please double check)
then the problem is NOT simply that the server offers only export ciphers.

For the meaning of that error code, see the list of error code numbers at
http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html#1037283

As you can see, that error code is not reporting some problem with the 
choice of cipher suite.  It is reporting "invalid arguments", which is 
indicative of a programming error.  So I think your analysis (in the 
too-long summary) of the cause of the problem was incorrect.  It's better to 
report the observed behavior in the summary than to report an analysis of it.

If you will run ssltap (with the arguments -sxlp) and capture a connection
that gives the error you reported, and will attach to this bug the output of
ssltap AND the cert.00n files that ssltap creates (with type application/
octet-stream) then I will look at them.  Based on my findings, I may reopen
this bug and change it to a different product/component.

Comment 4

[Ralf Hauser]

Nelson,

thx for the hint - as per Bug 281161, I finally managed to finish the ssltap
installation, but probably there was still something wrong with how I operated it.

Comment 5

[Ralf Hauser]

Attachment: export.ssltap

but it seems that I can reproduce the -8187 error. When doing 

<<myPC> openssl s_server -accept 443 -cipher EXPORT
Enter pass phrase for server.pem:
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
ERROR
shutting down SSL
CONNECTION CLOSED
ACCEPT>>

When putting ssltap inbetween and accessing https://localhost:1924 with
firefox, the error no longer comes up, but firefox just hangs and ssltap
produces the attached.

Comment 6

[Ralf Hauser]

Attachment: exportWWW.ssl

with ssltap inbetween, the openssl output was:
<<myPC> openssl s_server -accept 443 -cipher EXPORT
Enter pass phrase for server.pem:
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
-----BEGIN SSL SESSION PARAMETERS-----
MHUCAQECAgMABAIAZAQgXMm90jQKbWKiL/9NnryLxeJXHCvob8YQ5DsDxOKJoN8E
MPoh1vn+NgjCo2HZ9Jf2XRVeujI0oNjCQaMrJRQ9vUpxRK+1XM8mO2WvISinbZTo
96EGAgRC2m0bogQCAgEspAYEBAEAAAA=
-----END SSL SESSION PARAMETERS-----
Shared
ciphers:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:RC4-MD5:RC4-SHA:AE

S128-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:EXP1

024-RC4-SHA:EXP1024-DES-CBC-SHA:EXP-RC4-MD5:EXP-RC2-CBC-MD5
CIPHER is EXP1024-RC4-SHA
GET / HTTP/1.1
Host: localhost:1924
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8)
Gecko/20050511 Firefox/1.0.4
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

ERROR
shutting down SSL
CONNECTION CLOSED
ACCEPT>>

When starting openssl with the "-www" option, a intelligible error message
comes up that warns about low-grade encryption.

So, in conclusion, the problem might be one of the test-setup with the openssl
s_server if not provided with the -www option.

Just for completeness, I attach that ssltap output and the openssl output:
<<myPC>openssl s_server -accept 443 -cipher EXPORT -www
Enter pass phrase for server.pem:
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
ACCEPT>>

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Both these ssltap outputs show correct browser behavior.

In the one that you said "hung", the SLS handshake completed normally,
the browser sent the http request to the server, and the server did 
not reply, which caused the apparent hang.  That's not a browser error.

If you can reproduce the -8187 error with ssltap running, please attach
that ssltap output here, AND attach the cert.00n files that ssltap creates
here also.  

Until then, I'll leave this bug as a dup.