| Issue 5894: | Bank of America Military Bank Login Page Inaccessible on Vista with the new HTTP stack | |
| 4 people starred this issue and may be notified of changes. | Back to list |
Sign in to add a comment
|
Chrome Version : 1.0.156.0 (7480) URLs (if applicable) : https://militarybankonline.bankofamerica.com/efs/servlet/military/login.jsp Other browsers tested: IE 7 & Firefox 3 Add OK or FAIL after other browsers where you have tested this issue: Safari 3: Not Tested Firefox 3: OK IE 7: OK What steps will reproduce the problem? 1. goto https://www.bankofamerica.com/military/index.cfm? template=transition_overview 2. select a State to store cookie 3. again goto https://www.bankofamerica.com/military/index.cfm? template=transition_overview 4. Click on Sign In button under "Military Bank Online" (right half of page over half way down) What is the expected result? A page with username and password text entry boxes, and sign in button (see attached screenshot) What happens instead? This webpage is not available. The webpage at https://militarybankonline.bankofamerica.com/efs/servlet/military/login.jsp might be temporarily down or it may have moved permanently to a new web address. More information on this error Below is the original error message Error 2 (net::ERR_FAILED): Unknown error. Please provide any additional information below. Attach a screenshot if possible.
Comment
1
by
suna...@chromium.org,
Dec 29, 2008
Cc: anan...@chromium.org
,
Dec 29, 2008
I tried it, still doesn't work. try going directly to this link: https://militarybankonline.bankofamerica.com/efs/servlet/military/login.jsp when i goto that page i get the message i posted under "What happens instead?" with or without the --new-http however when i use IE7 or Firefox 3 it works just fine
,
Dec 29, 2008
see the attached picture to make sure you are seeing that exact page also i updated to 1.0.156.0 (7485) and it still doesn't work.
,
Dec 29, 2008
I just tried this again in Windows XP Pro SP3 and it worked just fine. So the problem has something to do with Vista and Chromium
,
Dec 29, 2008
The above URL works with 154.42 but not with latest Chromium builds Request using 154.42 --------------------- CONNECT militarybankonline.bankofamerica.com:443 HTTP/1.0 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.42 Safari/525.19 Host: militarybankonline.bankofamerica.com:443 Content-Length: 0 Proxy-Connection: Keep-Alive The data sent represents a SSLv3-compatible ClientHello handshake. For your convenience, the data is extracted below. Major Version: 3 Minor Version: 1 Random: 49 59 94 FA A7 33 0A B6 23 C8 C5 36 9E 7A 0D 44 9A E3 D2 BB B5 4E 14 A5 34 19 D7 25 6B 7E 1B 7F SessionID: empty Ciphers: [002F] TLS_RSA_AES_128_SHA [0035] TLS_RSA_AES_256_SHA [0005] SSL_RSA_WITH_RC4_128_SHA [000A] SSL_RSA_WITH_3DES_EDE_SHA [C009] TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA [C00A] TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA [C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA [C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA [0032] TLS_DHE_DSS_WITH_AES_128_SHA [0038] TLS_DHE_DSS_WITH_AES_256_SHA [0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA [0004] SSL_RSA_WITH_RC4_128_MD5 Response using 154.42 --------------------- HTTP/1.0 200 Connection Established Timestamp: 19:26:50:1777 Request using 155.0 --------------------- CONNECT militarybankonline.bankofamerica.com:443 HTTP/1.1 Host: militarybankonline.bankofamerica.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/528.7 (KHTML, like Gecko) Chrome/1.0.155.0 Safari/528.7 The data sent represents a SSLv3-compatible ClientHello handshake. For your convenience, the data is extracted below. Major Version: 3 Minor Version: 1 Random: 49 59 95 0E 19 67 29 D8 CE 4F 68 9F 80 7B 55 14 63 93 B3 ED E5 2A 05 BD 17 A4 8A 9D B7 88 E7 F8 SessionID: empty Ciphers: [002F] TLS_RSA_AES_128_SHA [0035] TLS_RSA_AES_256_SHA [0005] SSL_RSA_WITH_RC4_128_SHA [000A] SSL_RSA_WITH_3DES_EDE_SHA [C009] TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA [C00A] TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA [C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA [C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA [0032] TLS_DHE_DSS_WITH_AES_128_SHA [0038] TLS_DHE_DSS_WITH_AES_256_SHA [0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA [0004] SSL_RSA_WITH_RC4_128_MD5 Response using 155.0 --------------------- HTTP/1.1 200 Connection Established Timestamp: 19:27:10:3256 ***The only difference that I could see is that 154.42 is using protocol HTTP/1.0 and 155.0 is using HTTP/1.1***
Status: Untriaged
Labels: -Area-Misc Area-BrowserBackend Chrome-specific NeedsEngReview
,
Jan 14, 2009
(No comment was entered for this change.)
Status: Assigned
Owner: ero...@chromium.org Labels: Mstone-2.0 NewHTTP
,
Jan 14, 2009
I have been unable to reproduce this. What happens when you use this version of chrome: http://build.chromium.org/buildbot/snapshots/chromium-rel-xp/8044/chrome-win32.zip (Extract the zip and run chrome.exe). Thanks
,
Jan 14, 2009
Even I can't reproduce it now with Chromium 1.0.156.0 (Developer Build 7480)[Version used by reporter].
,
Jan 14, 2009
are either of you using vista? like I said earlier when I try it in XP it works fine but when I do it in Vista it gives me that error even on latest build. I will try on a fresh vanilla installation of Vista in VM to see if it is an operating system setting specific to me.
,
Jan 15, 2009
Oh Yes. This works fine in XP but not on Vista. I could still reproduce it with Chromium 2.0.157.0 (Developer Build 7833) but not with Chrome 1.0.154.43
,
Jan 16, 2009
(No comment was entered for this change.)
Cc: w...@chromium.org
,
Jan 20, 2009
The ERR_FAILED is being generated by SSLClientSocketWin::DoHandshakeReadComplete:
if (result == 0 && !ignore_ok_result_)
--> return ERR_FAILED; // Incomplete response :(
So I am guessing that in order to reach this, we must have written something that the
server didn't like during SSLClientSocketWin::DoHandshakeWrite().
,
Jan 20, 2009
(No comment was entered for this change.)
Owner: w...@chromium.org
,
Jan 20, 2009
Eric and I looked at the SSL packet trace. We found that
the server is a TLS-intolerant server.
On XP, Google Chrome 2.0.157.2 sends this SSL ClientHello
message to the server:
--> [
(70 bytes of 65)
SSLRecord { [Tue Jan 20 18:06:37 2009]
0: 16 03 01 00 41 |....A
type = 22 (handshake)
version = { 3,1 }
length = 65 (0x41)
handshake {
0: 01 00 00 3d |...=
type = 1 (client_hello)
length = 61 (0x00003d)
ClientHelloV3 {
client_version = {3, 1}
random = {...}
0: 49 76 83 2d d3 65 66 86 3e f1 86 26 c7 38 e2 86 | Iv.-.ef.>..&.8..
10: 23 cd 5b 0d f6 f5 2e b3 44 91 6c 13 d2 e4 16 b2 | #.[.....D.l.....
session ID = {
length = 0
contents = {..}
}
cipher_suites[11] = {
(0x0004) SSL3/RSA/RC4-128/MD5
(0x0005) SSL3/RSA/RC4-128/SHA
(0x000a) SSL3/RSA/3DES192EDE-CBC/SHA
(0x0009) SSL3/RSA/DES56-CBC/SHA
(0x0064) TLS/RSA-EXPORT1024/RC4-56/SHA
(0x0062) TLS/RSA-EXPORT1024/DES56-CBC/SHA
(0x0003) SSL3/RSA/RC4-40/MD5
(0x0006) SSL3/RSA/RC2CBC40/MD5
(0x0013) SSL3/DHE-DSS/DES192EDE3CBC/SHA
(0x0012) SSL3/DHE-DSS/DES56-CBC/SHA
(0x0063) TLS/DHE-DSS_EXPORT1024/DES56-CBC/SHA
}
compression[1] = { 00 }
}
}
}
]
On Vista, Google Chrome sends a different SSL ClientHello
message, which causes the server to close the underlying
TCP connection immediately:
--> [
(92 bytes of 87)
SSLRecord { [Tue Jan 20 17:56:46 2009]
0: 16 03 01 00 57 |....W
type = 22 (handshake)
version = { 3,1 }
length = 87 (0x57)
handshake {
0: 01 00 00 53 |...S
type = 1 (client_hello)
length = 83 (0x000053)
ClientHelloV3 {
client_version = {3, 1}
random = {...}
0: 49 76 80 de 9f e8 29 53 cc 9c 42 d7 95 86 c6 4f | Iv....)S..B....O
10: 0e fb c2 29 3d 02 c2 e8 f3 65 4a 12 7e a6 b7 9c | ...)=....eJ.~...
session ID = {
length = 0
contents = {..}
}
cipher_suites[12] = {
(0x002f) TLS/RSA/AES128-CBC/SHA
(0x0035) TLS/RSA/AES256-CBC/SHA
(0x0005) SSL3/RSA/RC4-128/SHA
(0x000a) SSL3/RSA/3DES192EDE-CBC/SHA
(0xc009) TLS/ECDHE-ECDSA/AES128-CBC/SHA
(0xc00a) TLS/ECDHE-ECDSA/AES256-CBC/SHA
(0xc013) TLS/ECDHE-RSA/AES128-CBC/SHA
(0xc014) TLS/ECDHE-RSA/AES256-CBC/SHA
(0x0032) TLS/DHE-DSS/AES128-CBC/SHA
(0x0038) TLS/DHE-DSS/AES256-CBC/SHA
(0x0013) SSL3/DHE-DSS/DES192EDE3CBC/SHA
(0x0004) SSL3/RSA/RC4-128/MD5
}
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. [Tue Jan 20 17:56:46 2009]
You can see that the lists of cipher suites are different
in the ClientHello messages. Moreover, the Vista ClientHello
message has two extensions (for elliptic curve cryptography).
Most likely, the server doesn't like ClientHello extensions.
We have code in http_network_transaction.cc for handling
TLS-intolerant servers, but it requires the error code from
SSL handshake to be ERR_SSL_PROTOCOL_ERROR or
ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Since we're returning
ERR_FAILED now, the TLS-intolerant server handling code is
not activated. The fix is most likely to return
ERR_SSL_PROTOCOL_ERROR instead.
Status: Started
Cc: ero...@chromium.org Labels: -NeedsEngReview
,
Jan 21, 2009
The following revision refers to this bug:
http://src.chromium.org/viewvc/chrome?view=rev&revision=8377
------------------------------------------------------------------------
r8377 | wtc@chromium.org | 2009-01-21 11:16:05 -0800 (Wed, 21 Jan 2009) | 9 lines
Changed paths:
M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/ssl_client_socket_win.cc?r1=8377&r2=8376
Return ERR_SSL_PROTOCOL_ERROR instead of the default
ERR_FAILED when we read EOF during the SSL handshake.
The ERR_SSL_PROTOCOL_ERROR error code will allow the
TLS-intolerant server handling code in
http_network_transaction.cc to kick in if necessary.
R=eroman
BUG=5894
Review URL: http://codereview.chromium.org/18606
------------------------------------------------------------------------
,
Jan 21, 2009
Fixed in r8377. Until this fix shows up in the Dev channel, you can work around this bug by turning off TLS 1.0. Go to Control Panel > Internet Options > Advanced > Settings > Security, uncheck the "Use TLS 1.0" box, and click the "OK" button. Restart Chromium. Remember to turn TLS 1.0 back on when you get the bug fix because TLS 1.0 is more secure than SSL 3.0.
Summary: Bank of America Military Bank Login Page Inaccessible on Vista with the new HTTP stack
Status: Fixed
,
Jan 21, 2009
The TLS intolerant server at https://militarybankonline.bankofamerica.com/efs/servlet/military/login.jsp identifies itself as "Server: IBM_HTTP_Server/6.0.2.15 Apache/2.0.47 (Unix) DAV/2". I also found that WinHTTP handles this particular TLS intolerant server transparently on Vista. WinHTTP doesn't report any error to us at all, so our own TLS intolerant server handling code isn't being used. In any case, with my fix, the new HTTP stack (plus our own TLS intolerant server handling code) generates the same SSL packet trace as WinHTTP does.
,
Dec 18, 2009
(No comment was entered for this change.)
Labels: -Area-BrowserBackend Area-Internals Internals-Network
|
||||||||||
| ► Sign in to add a comment | |||||||||||
