Useless error message failing to connect to vodafone.net

RESOLVED INVALID

Status

()

Core
Security: PSM
--
major
RESOLVED INVALID
11 years ago
11 years ago

People

(Reporter: Joe, Assigned: kaie)

Tracking

1.8 Branch
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.8.1) Gecko/20061010 Firefox/2.0

When I go to the vodafone.net website it tells me that it is busy but works fine in i.e.6

Reproducible: Always

Steps to Reproduce:
1.go to website
2.
3.

Actual Results:  
site shows The connection was interrupted
www.vodafone.net redirects based on browser (sniffer ?)
Opera is redirected to a loginpage that fails to load prolly something similar for Firefox.

Maybe this is a dupe of Bug 214010 that should be reopened.
Status: UNCONFIRMED → NEW
Component: General → English Other
Ever confirmed: true
Product: Firefox → Tech Evangelism
Nothing to do with redirection, and everything to do with SSL quality, though the part of this that I think is most a bug is that you would never know that from the "connection interrupted" error message that you see. In fact, the problem is that the pref security.ssl3.rsa_1024_rc4_56_sha is now disabled, so that rather than seeing and ignoring a "weak security" dialog like you did in Fx 1.5, you now see a totally bogus failure.
Assignee: nobody → kengert
Component: English Other → Security: PSM
Product: Tech Evangelism → Core
QA Contact: general
Summary: Website can not be accessed always shows as being busy → Useless error message failing to connect to vodafone.net
Version: unspecified → 1.8 Branch
(Assignee)

Comment 3

11 years ago
When the vodafone.net server receives your client hello, it simply disconnects.

This results in the correct error page "connection terminated unexpectedly".

Probably the server software is unable to understand our SSL client hello (which should be standards compliant) and behaves incorrectly by terminating the connection.


[kaie@kaiez1:~]$ ssltap -h -s www.vodafone.net:443
Looking up "www.vodafone.net"...
Proxy socket ready and listening
Connected to www.vodafone.net:443
--> [
   0: 16 03 01 00  77 01 00 00  73 03 01 00  0d 61 bb fa  | ....w...s....a..
  10: 80 07 62 e7  19 cd c7 39  de a1 79 7e  32 fa 80 c3  | ..b....9..y~2...
  20: 76 7a f7 b9  9c 30 9c aa  17 69 b8 00  00 38 c0 0a  | vz...0...i...8..
  30: c0 14 00 39  00 38 c0 0f  c0 05 00 35  c0 07 c0 09  | ...9.8.....5....
  40: c0 11 c0 13  00 33 00 32  c0 0c c0 0e  c0 02 c0 04  | .....3.2........
  50: 00 04 00 05  00 2f c0 08  c0 12 00 16  00 13 c0 0d  | ...../..........
  60: c0 03 fe ff  00 0a 01 00  00 12 00 0a  00 08 00 06  | ................
  70: 00 17 00 18  00 19 00 0b  00 02 01 00              |............
(124 bytes of 119)
SSLRecord { [Wed Nov 29 16:12:04 2006]
   type    = 22 (handshake)
   version = { 3,1 }
   length  = 119 (0x77)
   handshake {
      type = 1 (client_hello)
      length = 115 (0x000073)
         ClientHelloV3 {
            client_version = {3, 1}
            random = {...}
            session ID = {
                length = 0
                contents = {..}
            }
            cipher_suites[28] = {
                (0xc00a) TLS/ECDHE-ECDSA/AES256-CBC/SHA
                (0xc014) TLS/ECDHE-RSA/AES256-CBC/SHA
                (0x0039) TLS/DHE-RSA/AES256-CBC/SHA
                (0x0038) TLS/DHE-DSS/AES256-CBC/SHA
                (0xc00f) TLS/ECDH-RSA/AES256-CBC/SHA
                (0xc005) TLS/ECDH-ECDSA/AES256-CBC/SHA
                (0x0035) TLS/RSA/AES256-CBC/SHA
                (0xc007) TLS/ECDHE-ECDSA/RC4-128/SHA
                (0xc009) TLS/ECDHE-ECDSA/AES128-CBC/SHA
                (0xc011) TLS/ECDHE-RSA/RC4-128/SHA
                (0xc013) TLS/ECDHE-RSA/AES128-CBC/SHA
                (0x0033) TLS/DHE-RSA/AES128-CBC/SHA
                (0x0032) TLS/DHE-DSS/AES128-CBC/SHA
                (0xc00c) TLS/ECDH-RSA/RC4-128/SHA
                (0xc00e) TLS/ECDH-RSA/AES128-CBC/SHA
                (0xc002) TLS/ECDH-ECDSA/RC4-128/SHA
                (0xc004) TLS/ECDH-ECDSA/AES128-CBC/SHA
                (0x0004) SSL3/RSA/RC4-128/MD5
                (0x0005) SSL3/RSA/RC4-128/SHA
                (0x002f) TLS/RSA/AES128-CBC/SHA
                (0xc008) TLS/ECDHE-ECDSA/3DES-EDE-CBC/SHA
                (0xc012) TLS/ECDHE-RSA/3DES-EDE-CBC/SHA
                (0x0016) SSL3/DHE-RSA/3DES192EDE-CBC/SHA
                (0x0013) SSL3/DHE-DSS/DES192EDE3CBC/SHA
                (0xc00d) TLS/ECDH-RSA/3DES-EDE-CBC/SHA
                (0xc003) TLS/ECDH-ECDSA/3DES-EDE-CBC/SHA
                (0xfeff) SSL3/RSA-FIPS/3DESEDE-CBC/SHA
                (0x000a) SSL3/RSA/3DES192EDE-CBC/SHA
            }
            compression[1] = { 00 }
            extensions[18] = {
              extension type elliptic_curves, length [8] = {
   0: 00 06 00 17  00 18 00 19                          |........
              }
              extension type ec_point_formats, length [2] = {
   0: 01 00                                            |..
              }
            }
         }
   }
}
]
Read EOF on Server socket. [Wed Nov 29 16:12:04 2006]
Read EOF on Client socket. [Wed Nov 29 16:12:04 2006]
Connection 1 Complete [Wed Nov 29 16:12:04 2006]
(Assignee)

Comment 4

11 years ago
If my diagnosis is correct, the following is what happens:

Whenever your server encounters that the client did not offer a cipher supported by the server, it simply closes the connections.

According to my understanding, this is incorrect behaviour. The client does not have another choice but reporting "connection closed unexpectedly".

The SSL protocol defines mechanisms that'd allow the server to report a "no ciphers in common" problem. If your server did, the client would correctly report that.


I was able to get a connection by manually enabling the weak ciphers (<128bit) that we recently disabled.

I believe this proves that my above statements are correct.


I'm closing this bug as INVALID.
Please reopen if you can show the problem is on the client side.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INVALID
(Assignee)

Comment 5

11 years ago
As of today, an example for a site that uses weak ciphers only, but where the server software is behaving correctly: https://secureads.ft.com/
On that site the client reports "server is using a security protocol which isn't enabled"
You need to log in before you can comment on or make changes to this bug.