Issue 178672 in chromium: 103 error at SSL sites

[chro...@googlecode.com]

Status: Unconfirmed
Owner: ----
CC: kenji...@chromium.org
Labels: Type-Bug Pri-2 Area-Undefined Hotlist-ConOps

New issue 178672 by nik...@chromium.org: 103 error at SSL sites
http://code.google.com/p/chromium/issues/detail?id=178672

Users are reporting they cannot log in to various websites since M25. It
seems like many of them are getting Error 103 (net::
ERR_CONNECTION_ABORTED): Unknown Error at SSL sites. I can repro with one
website.

Chrome Version: 26.0.1403.0 (Official build 180337) m, 27.0.1423.0
(Official build 184590) canary
OS: Windows 7 or Server 2008 R2 SP1 64 bit
URL: https://employment.en.japan.com/signup/
I can access this page from IE and Firefox on Win7, also on Chrome (M25) on
Mac.

Steps to repro:
Visit the URL: https://employment.en-japan.com or
https://employment.en-japan.com/signup/
Instead of seeing the page, you see Error 103

I can access http://employment.en-japan.com

Other websites that users reported (but I can't repro):
- Hotmail
- AOL
- nifty.com
- Yahoo Mail


--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Updates:
Owner: nik...@chromium.org
Labels: -Area-Undefined Area-Internals Action-FeedbackNeeded
Internals-Network

Comment #1 on issue 178672 by kenji...@chromium.org: 103 error at SSL
sites
http://code.google.com/p/chromium/issues/detail?id=178672

Can you attach a log from chrome://net-internals when you repro the issue
on https://employment.en.japan.com/signup/ ? Thanks.

[chro...@googlecode.com]

Updates:
Labels: OS-Windows

Comment #2 on issue 178672 by kenji...@chromium.org: 103 error at SSL
sites
http://code.google.com/p/chromium/issues/detail?id=178672

Oops the correct URL is
- https://employment.en-japan.com/signup/
not
- https://employment.en.japan.com/signup/

No repro on:
- Chrome OS 25.0.1364.87 (Official Build 182409) beta.
- Chrome for Android beta 25.0.1364.122

[chro...@googlecode.com]

Updates:
Labels: -Internals-Network Internals-Network-SSL

Comment #3 on issue 178672 by will...@chromium.org: 103 error at SSL sites
http://code.google.com/p/chromium/issues/detail?id=178672

(No comment was entered for this change.)

[chro...@googlecode.com]

Updates:
Status: Assigned
Owner: a...@chromium.org
Cc: nik...@chromium.org
Labels: -Action-FeedbackNeeded

Comment #7 on issue 178672 by kenji...@chromium.org: 103 error at SSL
sites
http://code.google.com/p/chromium/issues/detail?id=178672

I think these are the interesting parts:

for log attached to #5:
t=1362018301931 [st= 0] +SOCKET_ALIVE [dt=57]
--> source_dependency = 2089 (CONNECT_JOB)
t=1362018301931 [st= 0] +TCP_CONNECT [dt=13]
--> address_list = ["210.199.175.10:443"]
t=1362018301931 [st= 0] TCP_CONNECT_ATTEMPT [dt=13]
--> address = "210.199.175.10:443"
t=1362018301944 [st=13] -TCP_CONNECT
--> source_address = "192.168.147.4:59139"
t=1362018301944 [st=13] +SOCKET_IN_USE [dt=44]
--> source_dependency = 2088 (CONNECT_JOB)
t=1362018301944 [st=13] +SSL_CONNECT [dt=44]
t=1362018301944 [st=13] SOCKET_BYTES_SENT
--> byte_count = 198
t=1362018301957 [st=26] SOCKET_BYTES_RECEIVED
--> byte_count = 1280
t=1362018301958 [st=27] SOCKET_BYTES_RECEIVED
--> byte_count = 1280
t=1362018301969 [st=38] SOCKET_BYTES_RECEIVED
--> byte_count = 345
t=1362018301972 [st=41] SOCKET_BYTES_SENT
--> byte_count = 310
t=1362018301988 [st=57] SOCKET_READ_ERROR
--> net_error = -103 (ERR_CONNECTION_ABORTED)
--> os_error = 0
t=1362018301988 [st=57] SSL_HANDSHAKE_ERROR
--> net_error = -103 (ERR_CONNECTION_ABORTED)
--> ssl_lib_error = -5928
t=1362018301988 [st=57] SOCKET_READ_ERROR
--> net_error = -101 (ERR_CONNECTION_RESET)
--> os_error = 10054
t=1362018301988 [st=57] -SSL_CONNECT
--> net_error = -103 (ERR_CONNECTION_ABORTED)
t=1362018301988 [st=57] -SOCKET_IN_USE
t=1362018301988 [st=57] -SOCKET_ALIVE


For the log attached to #6:
t=1362020631382 [st= 0] +SOCKET_ALIVE [dt=141]
--> source_dependency = 285 (CONNECT_JOB)
t=1362020631382 [st= 0] +TCP_CONNECT [dt=11]
--> address_list = ["211.18.191.77:443"]
t=1362020631382 [st= 0] TCP_CONNECT_ATTEMPT [dt=11]
--> address = "211.18.191.77:443"
t=1362020631393 [st= 11] -TCP_CONNECT
--> source_address = "192.168.147.4:59309"
t=1362020631394 [st= 12] +SOCKET_IN_USE [dt=129]
--> source_dependency = 284 (CONNECT_JOB)
t=1362020631394 [st= 12] +SSL_CONNECT [dt=129]
t=1362020631394 [st= 12] SOCKET_BYTES_SENT
--> byte_count = 188
t=1362020631405 [st= 23] SOCKET_BYTES_RECEIVED
--> byte_count = 1280
t=1362020631405 [st= 23] SOCKET_BYTES_RECEIVED
--> byte_count = 1280
t=1362020631509 [st=127] SOCKET_BYTES_RECEIVED
--> byte_count = 123
t=1362020631511 [st=129] SOCKET_BYTES_SENT
--> byte_count = 182
t=1362020631522 [st=140] SOCKET_READ_ERROR
--> net_error = -103
(ERR_CONNECTION_ABORTED)
--> os_error = 0
t=1362020631523 [st=141] SSL_HANDSHAKE_ERROR
--> net_error = -103
(ERR_CONNECTION_ABORTED)
--> ssl_lib_error = -5928
t=1362020631523 [st=141] SOCKET_READ_ERROR
--> net_error = -101 (ERR_CONNECTION_RESET)
--> os_error = 10054
t=1362020631523 [st=141] -SSL_CONNECT
--> net_error = -103 (ERR_CONNECTION_ABORTED)
t=1362020631523 [st=141] -SOCKET_IN_USE
t=1362020631523 [st=141] -SOCKET_ALIVE



agl@: do you need the actual bytes sent/received or is this enough for a
start?

[chro...@googlecode.com]

Comment #9 on issue 178672 by lip...@google.com: 103 error at SSL sites
http://code.google.com/p/chromium/issues/detail?id=178672

RU and EN users report that this error might be caused by the latest
Kaspersky update. Please see the thread:
http://productforums.google.com/forum/#!topic/chrome/HEfvBmJkTsI/discussion

[chro...@googlecode.com]

Comment #10 on issue 178672 by kenji...@chromium.org: 103 error at SSL
sites
http://code.google.com/p/chromium/issues/detail?id=178672

I am quite sure that nikeda@ does not have Kapersky installed.
nikeda@: could you try on one of the Windows 8 test devices or if available
a consumer Windows machine without anything fancy installed on it?

lipich@: yours might be a different issue. Could you file a new bug and
attach chrome://net-internals logs from users?

[chro...@googlecode.com]

Comment #11 on issue 178672 by a...@chromium.org: 103 error at SSL sites
http://code.google.com/p/chromium/issues/detail?id=178672

lipich: thanks for pointing out the support thread. I suspect that's a
different issue and I've pointed Kaspersky at it.

However, I cannot reproduce this issue, even on Windows.

I've a Windows 7 VM with 27.0.1425.2 and
https://www.wakasa.jp/shopping/cart/ loads fine. As does the URL from #1.

We've only got a confirmed repo from one person so far, right? Could it be
something on their network?

[chro...@googlecode.com]

Updates:
Labels: -Action-FeedbackNeeded Mstone-26

Comment #13 on issue 178672 by kenji...@chromium.org: 103 error at SSL
sites
http://code.google.com/p/chromium/issues/detail?id=178672

I was able to repro the second example but not the first one.
Everything is working fine on Chrome 25

On Chrome canary
1. go to http://www.wakasa.jp/
2. click 買い物カゴを見る on the right side (orange patch)
3. you should end up on https://www.wakasa.jp/shopping/cart/ and get a 103
error

I will attach logs from 25 and Canary for comparison and try on a second
machine for good measure.


Google Chrome 27.0.1414.2 (Official Build 182971) canary
OS Windows
WebKit 537.32 (@143036)
JavaScript V8 3.17.1
Flash 11.6.602.167
ユーザー エージェント Mozilla/5.0 (Windows NT 6.1; WOW64)
AppleWebKit/537.32 (KHTML, like Gecko) Chrome/27.0.1414.2 Safari/537.32
コマンドライン "C:\Users\.....\AppData\Local\Google\Chrome
SxS\Application\chrome.exe" --no-startup-window --flag-switches-begin
--enable-instant-extended-api --enable-views-textfield
--sync-keystore-encryption --flag-switches-end

バリエーション 853359fa-eba72da
5f9f065f-15eb91be
5666f941-a27919f0
dddcfcd0-4ad60575
e353f218-39c30599
b03ddc1f-75e383c2
f9b252d0-fd526c81
b533da8e-f23d1dea
65957c53-43c7ff93
ca6785ad-766fa2d
3709139-766fa2d
9c507a5f-766fa2d
d86b76a4-766fa2d
60f3499f-766fa2d
76b86d80-766fa2d
7f6da4bf-70d6abf1
75f7fb7e-766fa2d
ad0f4b69-eac0f96c
262f996f-42d3ce07
24dca50e-4bb3e394
82d91892-3f4a17df
34f332ca-4ad60575
311b154d-3f4a17df
3028188e-d60b5a5f
f2cb3653-3d47f4f4
5a3c10b5-e1cc0f14
b2166a04-3846e3aa
244ca1ac-e1cc0f14
246fb659-bd104136
f296190c-5840db52
4442aae2-75cb33fc
75f0f0a0-4ad60575
e2b18481-7158671e
e7e71889-4ad60575

[chro...@googlecode.com]

Comment #14 on issue 178672 by kenji...@chromium.org: 103 error at SSL
sites
http://code.google.com/p/chromium/issues/detail?id=178672

I can also send logs with the actual bytes if it helps.

Attachments:
wakasa-canary-error.json 1.1 MB
wakasa-25-ok.json 3.0 MB

[chro...@googlecode.com]

Comment #15 on issue 178672 by kenji...@chromium.org: 103 error at SSL
sites
http://code.google.com/p/chromium/issues/detail?id=178672

Attached chrome flags from Canary just in case

Attachments:
flags.htm 301 KB

[chro...@googlecode.com]

Updates:
Owner: kenji...@chromium.org

Comment #16 on issue 178672 by kenji...@chromium.org: 103 error at SSL
sites
http://code.google.com/p/chromium/issues/detail?id=178672

Hmm, can't reproduce on my other win7 machine.
Will try to find what's going on.

[chro...@googlecode.com]

Comment #17 on issue 178672 by a...@chromium.org: 103 error at SSL sites
http://code.google.com/p/chromium/issues/detail?id=178672

(Back from traveling and can take a real look at this now.)

r.e. #13

The underlying issue is that the server is broken: it negotiates TLS 1.1
and then croaks on the ClientKeyExchange. I wondered whether it dislikes
the fact that we cap the ClientHello record version (perhaps it's expecting
the PMS version to match the record version, not the ClientHello version),
but that doesn't fix the problem either.

In the cases where this server works, we're performing fallback to TLS 1.0.
(If you click the padlock on a working version I believe that you'll always
find, under the Connection tab, a notice saying that the connection had to
be retried with an older version of the protocol.)

We are triggering the fallback because the socket error is
ERR_CONNECTION_RESET and we specifically remap that to
ERR_SSL_PROTOCOL_ERROR for TLS 1.1.

In the cases where it's not working, we're getting ERR_CONNECTION_ABORTED
and that's not remapped in the same way. It is not clear why
ERR_CONNECTION_RESET and ERR_CONNECTION_ABORTED are suddenly switching
around on Windows. The specific Chrome code hasn't changed although, as
these errors are related to socket buffering, it's possible that something
else changed to tickle this.

I believe that the flakiness is bad and should be fixed. The depressing fix
is to extend the TLS 1.1 fallback to include ERR_CONNECTION_ABORTED. The
aggressive fix is to remove the TLS 1.1 workaround for RESET as well and
break this site everywhere.

Since a TLS 1.1 -> TLS 1.0 fallback is not nearly as bad as an SSL 3.0
fallback, I suspect that we should concentrate any firepower on that
fallback and cave in this case.

[chro...@googlecode.com]

Comment #18 on issue 178672 by w...@chromium.org: 103 error at SSL sites
http://code.google.com/p/chromium/issues/detail?id=178672

Here is a list of the changes to net/socket in Chrome 25 (based on the
Chrome 24 branch revision 164863 and the Chrome 25 branch revision 173683):
http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/trunk/src/net/socket&range=164864:173683&mode=html

If the error code change is only observed on Windows, this may be a
result of r165170, which changed how we read from a TCP client socket
on Windows:

------------------------------------------------------------------------
r165170 | pme...@google.com | 2012-10-31 08:39:25 -0700 (Wed, 31 Oct 2012)
| 31 lines

Switch the TCP reads on Windows to use non-blocking/non-async I/O.
The Overlapped I/O was introducing delays when the networking stack
did not have enough data to fill the receive buffer.

This can be seen when loading pssplayground.com/ksimbili/webp.html
using a DSL connection profile on WebPagetest:
http://www.webpagetest.org/result/120830_MS_414849a6aa055bb853e7e5d51e1b29d8/
and manifests and increasingly long Time to First Byte for requests
further down the waterfall (expected values are < 90ms and it was
going over 150ms).

It is configured as a 50% field trial and can be forced through the
command-line for testing:
--overlapped-reads=on - default/existing behavior
--overlapped-reads=off - new read implementation

Trial-specific histograms are reported for page load times and
http request times. Specifically:
PLT.Abandoned
PLT.LoadType
PLT.BeginToFinish_NormalLoad
PLT.BeginToFinish_LinkLoadNormal
PLT.BeginToFinish_LinkLoadReload
PLT.BeginToFinish_LinkLoadStaleOk
Net.HttpJob.TotalTime
Net.HttpJob.TotalTimeSuccess
Net.HttpJob.TotalTimeCancel
Net.HttpJob.TotalTimeCached
Net.HttpJob.TotalTimeNotCached

Review URL: https://chromiumcodereview.appspot.com/10916016
------------------------------------------------------------------------

The Chrome 24 branch was created at revision 164863, which means r165170
first appeared in Chrome 25. (We may have asked pmeenan to wait until
Chrome 24 had branched to commit his CL.)

None of the changes to ssl_client_socket_nss.cc in Chrome 25 look
related to the (TCP) SOCKET_READ_ERROR change:
http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/trunk/src/net/socket/ssl_client_socket_nss.cc&range=164864:173683&mode=html

[chro...@googlecode.com]

Comment #22 on issue 178672 by a...@chromium.org: 103 error at SSL sites
http://code.google.com/p/chromium/issues/detail?id=178672

I've tried a Windows 7 machine against https://www.wakasa.jp/shopping/cart/
and I cannot reproduce the issue with --overlapped-reads=off.

kenjibaheux: if you have a setup that reproduces the issue, can you restart
Chrome, but with --overlapped-reads=on, confirm that the problem disappears
and then with --overlapped-reads=off and confirm that it comes back?

[chro...@googlecode.com]

Comment #23 on issue 178672 by w...@chromium.org: 103 error at SSL sites
http://code.google.com/p/chromium/issues/detail?id=178672

agl: I confirmed that the ERR_CONNECTION_ABORTED error is caused
by the use of non-blocking reads vs. overlapped reads in
tcp_client_socket_win.cc. So you can go ahead and check in your
CL, but please update the comments in your CL with this
conclusive finding.

nikeda,kenjibaheux: it would be nice if you could contact
https://www.wakasa.jp/ to find out more about their SSL/TLS
implementation. This server claims to support TLS 1.1 and TLS 1.2
in its ServerHello, but responds with a TCP reset to the client's
ClientKeyExchange, ChangeCipherSpec, and Finished sequence.

Details:

On Windows, I still see a proper TLS/SSL handshake (as opposed
to a version fallback) with https://employment.en-japan.com/signup/.
Note that the server only supports SSL 3.0.

On Windows I can reproduce the 103 ERR_CONNECTION_ABORTED error
with https://www.wakasa.jp/shopping/cart/.

In the debugger, I confirmed that the error code change is
caused by the use of non-blocking reads vs. overlapped/async
reads. I tested with two websites.

1) https://www.billpaysite.com/: this requires commenting out
the capRecordVersion code in ssl3_CompressMACEncryptRecord(),
net/third_party/nss/ssl/ssl3con.c. This server responds with a
TCP reset to the ClientHello.

2) https://www.wakasa.jp/shopping/cart/: this server responds
with a TCP reset to the ClientKeyExchange, ChangeCipherSpec,
Finished sequence.

In both cases, Chrome on Windows get ERR_CONNECTION_RESET if
overlapped reads are used, and ERR_CONNECTION_ABORTED if
non-blocking reads are used (in tcp_client_socket_win.cc).

I also tracked down why os_error = 0 in the SOCKET_READ_ERROR
event in the net-internals log. That is a benign problem.

I did several experiments. https://www.wakasa.jp/shopping/cart/
claims it supports TLS 1.1 and TLS 1.2. So if you advertise TLS 1.1
or TLS 1.2 in ClientHello, it will pick TLS 1.1 or TLS 1.2, respectively,
in ServerHello. This means the version encoded in the encrypted
RSA premaster secret is not the issue because there is only one
version. I also verified that the record layer version for our
initial ClientHello, which we capped at TLS 1.0, is not the problem.
This is further supported by IE having the same problem doing TLS 1.1
or TLS 1.2 with this server, because IE does not cap the record layer
version for the initial ClientHello.

I don't remember seeing this kind of incompatibility before. It
is new to me. So it is a good idea to find out more about the
SSL/TLS implementation used at this server.

I attached the TLS packet trace captured by the ssltap tool between
Chrome or IE (on Windows 7) and https://www.wakasa.jp/shopping/cart/.

Attachments:
ssltap-chrome.txt 7.2 KB
ssltap-ie-win7.txt 6.4 KB

[chro...@googlecode.com]

Comment #24 on issue 178672 by a...@chromium.org: 103 error at SSL sites
http://code.google.com/p/chromium/issues/detail?id=178672

wtc: do we want to alter the workaround, or remove the field-trial (or
both?). Should I send an email internally about the field-trial?

[chro...@googlecode.com]

Comment #25 on issue 178672 by bugdro...@chromium.org: 103 error at SSL
sites
http://code.google.com/p/chromium/issues/detail?id=178672#c25

The following revision refers to this bug:
http://src.chromium.org/viewvc/chrome?view=rev&revision=186218

------------------------------------------------------------------------
r186218 | a...@chromium.org | 2013-03-05T19:07:10.157658Z

Changed paths:
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/ssl_client_socket_nss.cc?r1=186218&r2=186217&pathrev=186218

net: also do TLS 1.1 -> 1.0 fallback on ERR_CONNECTION_ABORTED.

We currently perform TLS 1.1 -> 1.0 fallback for ERR_CONNECTION_RESET
to workaround some buggy servers. This change causes ERR_CONNECTION_ABORTED
to be treated like ERR_CONNECTION_RESET because, with non-blocking I/O,
it appears that we get this error rather than ERR_CONNECTION_RESET.
See r165170 and the bug.

See https://code.google.com/p/chromium/issues/detail?id=178672#c17

BUG=178672,179037

Review URL: https://codereview.chromium.org/12390059
------------------------------------------------------------------------

[chro...@googlecode.com]

Comment #26 on issue 178672 by vserap...@gmail.com: 103 error at SSL sites
http://code.google.com/p/chromium/issues/detail?id=178672

Also found that Chrome 25 has stopped sending Cookies when retrieving the
icon file associated with a page (Chrome 24 behaved properly). This is
breaking sites where the icon is also secured. Wonder if that is related
to not easily reproducible issues with problems loading certain sites.

[chro...@googlecode.com]

Comment #27 on issue 178672 by vserap...@gmail.com: 103 error at SSL sites
http://code.google.com/p/chromium/issues/detail?id=178672

See https://code.google.com/p/chromium/issues/detail?id=180579 for issue
where we found this Chrome 25 regression with retrieving the icon link for
a site.

[chro...@googlecode.com]

Updates:
Labels: Merge-Requested

Comment #28 on issue 178672 by kenji...@chromium.org: 103 error at SSL
sites
http://code.google.com/p/chromium/issues/detail?id=178672

agl@: I have confirmed that wakasa.jp works fine after your change with
Canary 27 build#186408). I am requesting a merge to 26 with the hope to
eventually get this up to 25.

will@: we plan to reach out wakasa.jp. Let us know if this isn't needed
anymore or if we should also try to reach out the owners of the other
websites listed here.

[chro...@googlecode.com]

Updates:
Cc: ke...@chromium.org tanya...@chromium.org

Comment #29 on issue 178672 by kenji...@chromium.org: 103 error at SSL
sites
http://code.google.com/p/chromium/issues/detail?id=178672

(No comment was entered for this change.)

[chro...@googlecode.com]

Updates:
Labels: -Merge-Requested Merge-Approved

Comment #30 on issue 178672 by dhar...@chromium.org: 103 error at SSL sites

[chro...@googlecode.com]

Updates:
Labels: -Merge-Approved merge-merged-1410

Comment #31 on issue 178672 by bugdro...@chromium.org: 103 error at SSL
sites
http://code.google.com/p/chromium/issues/detail?id=178672#c31

The following revision refers to this bug:

http://src.chromium.org/viewvc/chrome?view=rev&revision=186719

------------------------------------------------------------------------
r186719 | a...@chromium.org | 2013-03-07T15:48:52.603050Z

Changed paths:
M
http://src.chromium.org/viewvc/chrome/branches/1410/src/net/socket/ssl_client_socket_nss.cc?r1=186719&r2=186718&pathrev=186719

Merge 186218 to M26.

> net: also do TLS 1.1 -> 1.0 fallback on ERR_CONNECTION_ABORTED.

> We currently perform TLS 1.1 -> 1.0 fallback for ERR_CONNECTION_RESET
> to workaround some buggy servers. This change causes
> ERR_CONNECTION_ABORTED
> to be treated like ERR_CONNECTION_RESET because, with non-blocking I/O,
> it appears that we get this error rather than ERR_CONNECTION_RESET.
> See r165170 and the bug.

> See https://code.google.com/p/chromium/issues/detail?id=178672#c17

> BUG=178672,179037

> Review URL: https://codereview.chromium.org/12390059

TBR=a...@chromium.org
Review URL: https://codereview.chromium.org/12619002
------------------------------------------------------------------------

[chro...@googlecode.com]

Comment #34 on issue 178672 by w...@chromium.org: 103 error at SSL sites
http://code.google.com/p/chromium/issues/detail?id=178672

kenjibaheux: please reach out to www.wakasa.jp to find out more about their
SSL/TLS implementation. It is not necessary to reach out to the owners of
the other websites.

cbentzel: I found a way to retrieve more accurate error code (WSAECONNRESET
instead of WSAECONNABORTED) from non-blocking reads on Windows:
https://codereview.chromium.org/12546004/

The CL is going through code review. If that CL is accepted, then we should
be able to revert agl's CL (at least on the trunk).

[chro...@googlecode.com]

Comment #35 on issue 178672 by kenji...@chromium.org: 103 error at SSL
sites
http://code.google.com/p/chromium/issues/detail?id=178672

I just reached out to the admin in charge of wakasa.jp

[chro...@googlecode.com]

Comment #37 on issue 178672 by kenji...@chromium.org: 103 error at SSL
sites
http://code.google.com/p/chromium/issues/detail?id=178672

wtc@: I am having a hard time getting a repro from the admins of wakasa.jp.
They were not able to repro the issue (both --overlapped-reads=off and
--overlapped-reads=on worked). It did repro (failed and succeed) for me
though on Windows 7 with Chrome 25.

I am not sure if they are using Windows 7 or not. Would that be relevant?
Is there anything else to pay attention to? Or maybe only one of the server
is failing and the load balancer is giving us different results.

Thanks.

[chro...@googlecode.com]

Comment #38 on issue 178672 by a...@chromium.org: 103 error at SSL sites
http://code.google.com/p/chromium/issues/detail?id=178672

kenjibaheux: it may be timing related based on the description of the error
in MSDN.

However, we don't really need them to repo - we would just like to know
what they are using to terminate their SSL connections.

[chro...@googlecode.com]

Comment #39 on issue 178672 by paul.rob...@gmail.com: 103 error at SSL sites
http://code.google.com/p/chromium/issues/detail?id=178672

Guys, I can reproduce this issue...

Servers: Windows 2008, IIS7
Client: Windows 7, Chrome (>=25)

In a wireshark trace, the server resets the connection after the client
sends the initial HELO.

I have tried launching chrome with the --overlapped-reads=on parameter and
this does indeed resolve the problem.

Is there a server workaround that we can action to resolve the problem?
As chrome is auto-updating, this issue has become increasing prevalent on
our hosted sites in the past few weeks.

Many thanks

[chro...@googlecode.com]

Comment #40 on issue 178672 by a...@chromium.org: 103 error at SSL sites
http://code.google.com/p/chromium/issues/detail?id=178672

paul.robertson: please note that, as far as we know, this only affects
broken servers (or when a broken anti-virus on the local machine is
simulating a bad server). If you believe that you can reproduce with an
IIS7 server and a clean client, please give the hostname. (We may also need
a net-internals trace if the server doesn't appear to be broken in the way
that we know triggers this issue.)

[chro...@googlecode.com]

Comment #45 on issue 178672 by paul.rob...@gmail.com: 103 error at SSL sites
http://code.google.com/p/chromium/issues/detail?id=178672

alg: Great info, thanks.

The SSL connections to that server are being terminated by IIS since the
load balancing of the farm is simple NLB.

Are you aware of any windows or IIS settings that I can change to get the
servers to implement TLS correctly?

[chro...@googlecode.com]

Comment #46 on issue 178672 by a...@chromium.org: 103 error at SSL sites
http://code.google.com/p/chromium/issues/detail?id=178672

paul.robertson: there are a couple of KB articles about enabling TLS 1.1
and 1.2 support in SChannel (i.e. [1]). That might fix the issue, but it
needs a reboot.

However, you don't actually need to enable these protocols, you just need
TLS 1.0 implemented correctly, and I don't really believe that IIS is
broken in this manner.

Rather, I suspect that you have a firewall or some other device that's
causing the issue. When I look at a packet dump of a TLS 1.1 ClientHello vs
a TLS 1.0 ClientHello, the RST packet has a TTL of 53 and no options.
However, all other packets from the server, and all packets in the TLS 1.0
case, have a TTL of 117 and TCP timestamps.

That suggests that some device is fabricating the RST and I bet that if you
ran a packet dump on the server, it would see the /client/ sending the RST
because the device is sending them in both directions. The device seems to
use a base TTL of 64 but the true server is using 128 and both are 11 hops
from me.

[1] http://support.microsoft.com/kb/245030

[chro...@googlecode.com]

Updates:
Labels: TE-Verified-26.0.1410.33

Comment #47 on issue 178672 by ranjit...@chromium.org: 103 error at SSL
sites
http://code.google.com/p/chromium/issues/detail?id=178672

Verified all the above mentioned URLS on Chrome 26.0.1410.33 (Official
Build 187744) m and was unable to reproduce the issue.

Thanks.

[chro...@googlecode.com]

Comment #48 on issue 178672 by bugdro...@chromium.org: 103 error at SSL
sites
http://code.google.com/p/chromium/issues/detail?id=178672#c48

The following revision refers to this bug:

http://src.chromium.org/viewvc/chrome?view=rev&revision=188278

------------------------------------------------------------------------
r188278 | w...@chromium.org | 2013-03-15T07:18:02.103717Z

Changed paths:
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/ssl_client_socket_nss.cc?r1=188278&r2=188277&pathrev=188278
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/tcp_client_socket_win.cc?r1=188278&r2=188277&pathrev=188278

Retrieve more accurate error code (WSAECONNRESET vs.
WSAECONNABORTED) than what WSAEnumNetworkEvents reported
in network_events.iErrorCode[FD_CLOSE_BIT} by calling
recv() on the socket.

Document why spurious wakeups are expected and tolerated.

Revert r186218: net: also do TLS 1.1 -> 1.0 fallback on
ERR_CONNECTION_ABORTED. The workaround is no longer needed.

R=pme...@chromium.org,rva...@chromium.org,a...@chromium.org
BUG=180313,178672,179037
TEST=none

Review URL: https://chromiumcodereview.appspot.com/12468002
------------------------------------------------------------------------

[chro...@googlecode.com]

Comment #49 on issue 178672 by simonsai...@gmail.com: 103 error at SSL sites
http://code.google.com/p/chromium/issues/detail?id=178672

The webpage at http://www.idrapidleech.net/ might be temporarily down or it
may have moved permanently to a new web address.
Error 103 (net::ERR_CONNECTION_ABORTED): Unknown error.

same issue with me here but diferrent website

[chro...@googlecode.com]

Comment #50 on issue 178672 by gasm...@gmail.com: 103 error at SSL sites
http://code.google.com/p/chromium/issues/detail?id=178672

I regularly have this issue as well, for example on
https://secure.ogone.com/ncol/prod/orderstandard.asp just now. I will try
to capture a log next time, but it happens quite randomly. Also, I have
very little knowledge of the behind-the-scenes things, as I'm merely an end
user. My version is 26.0.1410.64 m by the way.

[chro...@googlecode.com]

Comment #51 on issue 178672 by laspina....@gmail.com: 103 error at SSL sites
http://code.google.com/p/chromium/issues/detail?id=178672

I found some strange behavior that might explain some of the "works for me"
runaround. I visited some of the sites mentioned by the other users running
into the issue, and they also worked for me... However, I was running into
this issue separately, on the staging site for my workplace (which is SSL
enabled), a site I visit often. It was receiving "Error 103

(net::ERR_CONNECTION_ABORTED): Unknown error".

Also, for the record, I don't have Kapersky, so not related to that issue...

It seems that this is potentially occurring with sites that have been
previously visited by the individual, and have cached data. I visited the
staging site that gave me issues in Incognito mode with no errors.
Additionally, clearing the cache and deleting the cookies/site data, with a
hard refresh or browser restart allowed the site to load properly outside
Incognito. For some reason, that seemed to clear whatever issue it was
hanging up on.

Also, just to verify (since I saw it as an issue in comment 44 above), this
is the message from the Connections tab for the SSL for the site I had an
issue with, after the cache-clear that allowed it to work (green lock icon
next to it, so I assume no issues with it...):
Your connection is encrypted with 128-bit encryption.
The connection uses TLS 1.0.
The connection is encrypted using RC4_128, with MD5 for message
authentication and RSA as the key exchange mechanism.
The Connection does not use SSL compression.
The server does not support the TSL renegotiation extension.

Chrome: Version 26.0.1410.64 m
Windows 7 Professional SP1.

[chro...@googlecode.com]

Updates:
Status: Fixed

Comment #52 on issue 178672 by w...@chromium.org: 103 error at SSL sites
http://code.google.com/p/chromium/issues/detail?id=178672

This bug has been fixed.

Note: ERR_CONNECTION_ABORTED is a low-level network error, which may occur
for reasons other than the bug fixed in this bug report.

[chro...@googlecode.com]

Updates:
Status: Verified

Comment #53 on issue 178672 by msrchan...@chromium.org: 103 error at SSL
sites
http://code.google.com/p/chromium/issues/detail?id=178672

Verified in Latest Stable Version: 27.0.1453.94.
No Network Errors observed.

Moving to Verified State.

[chro...@googlecode.com]

Comment #55 on issue 178672 by karank30...@gmail.com: 103 error at SSL sites
https://code.google.com/p/chromium/issues/detail?id=178672

Hi,

I am continuously getting the following error when running some of the
applications via chromedriver

[4264:4244:1102/083705:ERROR:ssl_client_socket_openssl.cc(1077)] handshake
faile
d; returned -1, SSL error code 1, net_error -103

Currently I am using
Chrome 46.0.2490.80 m
Chromedriver 2.19
Selenium(Webdriver) 2.44

[chro...@googlecode.com]

Comment #56 on issue 178672 by davi...@chromium.org: 103 error at SSL sites
https://code.google.com/p/chromium/issues/detail?id=178672

karank301111992: This bug is from 2013 and has since been fixed. Please
file a new bug.