Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 10 users
Status: Archived
Owner: ----
Closed: Aug 2015
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment
SSL POST REQUESTS
Reported by aminl...@gmail.com, Sep 26 2011 Back to list
Chrome Version       : 15.0.874.24
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5:
Firefox 4.x:
IE 7/8/9:

What steps will reproduce the problem?
1. Go to https://app.fluidsurveys.com/accounts/login/
2. Type anything for username/password
3. Use the request monitor and watch the request fail

What is the expected result?
If you use Chrome <= 14 it will either log you in or tell you bad password


What happens instead?


Please provide any additional information below. Attach a screenshot if
possible.

UserAgentString: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.24 Safari/535.2



 
Comment 1 by aminl...@gmail.com, Sep 26 2011
Sorry i hit submit too early.

What happens instead is that the request fails. If you use the network inspector the connection is aborted by the browser.
Comment 2 by aminl...@gmail.com, Sep 26 2011
And it works in every other browser tested, including all the ones in the above list.
Comment 3 by mmenke@chromium.org, Sep 28 2011
Labels: -Area-Undefined Area-Internals Internals-Network-SSL
Comment 4 by djm...@gmail.com, Oct 12 2011
We are seeing a very similar problem with an apache 2.2.17 based authentication plugin over ssl. 

Using chrome stable, FF 7,6,5,4,3, IE 6,7,8,9 we can post to our authentication plugin successfully, but with the current chrome beta, authentication fails, and we do not appear to be receiving the post data in our apache plugin. We're still testing to confirm exactly what we are getting from the post. 

What is interesting is that this ONLY occurs when using SSL. When we drop SSL, and go port 80 unsecure, authentication occurs successfully, and the plugin is receiving the post data. 

I'd be curious if you can authenticate to the site above if SSL was disabled. 
Comment 5 by aminl...@gmail.com, Oct 12 2011
You CAN authenticate with SSL off (tested on a dev instance). But for security purposes we prevent non SSL Authentication on fluidsurveys.com which is actually preventing anyone that uses chrome beta from logging into our service.
Comment 6 by agl@google.com, Oct 12 2011
djm...: if it broke in the latest beta but works with Chrome 14 then it's probably because you're assuming the whole HTTP request comes in a single record.

aminl...: I take a look later.
Comment 7 by djm...@gmail.com, Oct 12 2011
Has something changed in release 15 that it is now sending the request in multiple records? The post data that we're sending is 44 bytes. If this has changed, is this going to be a permanent change? And yes, we are assuming that the request is in a single record due to it being such a small post.

Also, I noticed that the site noted above is running cherokee, and our sites are running on apache, and we both seem to be affected by this similar problem. I first assumed it was only affecting apache until I looked closer at the site above. 

Thanks for the help!

Comment 8 by agl@chromium.org, Oct 12 2011
Yes, requests will be in multiple records from now on. See http://www.imperialviolet.org/2011/09/23/chromeandbeast.html

Firefox will make this change an in upcoming release and Microsoft are expected to do the same.
Comment 9 by djm...@gmail.com, Oct 12 2011
Thank you very much for the information, good to know.

Dean 
Comment 10 by aminl...@gmail.com, Oct 12 2011
So should we be pointing this bug out to the Cherokee/Apache teams?
Comment 11 by agl@chromium.org, Oct 12 2011
Given that most sites are functioning, I don't think Cherokee/Apache are to blame. At worst they are passing the fragmented HTTP request on.
Comment 12 by aminl...@gmail.com, Oct 12 2011
I don't know about Apache, but Cherokee is pretty hipster... Also we're not doing anything funky, it's just a vanilla SSL setup with a simple django webserver.
Comment 13 by djm...@gmail.com, Oct 13 2011
aminl -- If you're running django, you're probably using some type of translation layer/plugin, wsgi, fastcgi, etc. I've used wsgi and mod_python for apache. 

I'd suspect that the problem you're running into with the fragmented auth request probably lies somewhere in that layer... It's reading the request from apache and passing it into django... It may not be handling the fragmented request properly.

That's really a guess, but hope it helps.
Comment 14 by aminl...@gmail.com, Oct 13 2011
I sent this bug to the Cherokee team, and they have accepted it,
already one patch has been submitted... So hopefully the next Cherokee
update will be before chrome 15 goes stable...
Comment 15 by aminl...@gmail.com, Oct 14 2011
From http://code.google.com/p/cherokee/issues/detail?id=1284

online.wsj.com login (drop-down on right side) also fails on https login, but works if the form action is http.  Same symptoms where it works in all other browsers and Chrome <= 14
I can confirm this also breaks for Chrome 15 on OSX, so it's not Windows-specific.  This is a show-stopper for our site since we can't fix the corrupted request from the server side.
Comment 17 by agl@chromium.org, Oct 20 2011
leecook...: can you elaborate on the issue you see? This bug is about record splitting: the request isn't corrupted, but it might not be fully read by a single read call to the SSL library.
I see the problem now, and that there's an effort to fix it...my only concern is that web sites that aren't using a recent version of apache will have a 100% failure for secure POST requests, such as login.  If the remedy is to upgrade the servers, and appropriate fixes are available for the major server vendors, then it's not a problem...assuming sites upgrade before Chrome 15 hits the release channel.
Comment 19 by agl@chromium.org, Oct 20 2011
leecook...: I don't believe that there's a problem with Apache itself, although there does appear to be a problem with some frameworks on top of Apache.

Hopefully sites noticed during the beta and have fixed things as Chrome 15 will be stable soon.
Comment 20 by aminl...@gmail.com, Oct 25 2011
Congratulations, chrome, on breaking the web.
We installed Chrome beta version 15.0.874.102 beta-m and managed to reproduce the problem. However, this morning I tried testing it again and the problem was gone.
It turns out that Chrome updated itself automatically and now the version is 15.0.874.106. I verified it and indeed the previous version (102) reflects the problem, but the new version (106) does not.

This is running through an Apache-based Proxy Server.
Comment 22 by agl@chromium.org, Oct 27 2011
Yes, 15.0.874.106 doesn't include 1/n-1 record splitting and, based on policy, it's unlikely that the rest of the 15 series will. The change was more disruptive than the beta period had suggested and we're working with several large sites who need to update.

1/n-1 record splitting will continue on the beta and dev channels and will reappear in 6 weeks with Chrome 16.
Comment 23 by ste...@konink.de, Oct 27 2011
"we're working with several large sites"

Is that how it works these days, talking to large sites? What about full disclosure? This feature already costed a lot of support time from several open source communities. What about preference that a user can enable, or a post without the 1/n-1 upon a post failure?
Comment 24 Deleted
Comment 25 by agl@chromium.org, Oct 27 2011
There's nothing sensitive about this change. I think we've been clear about why it's happening. Opera, Chrome, Firefox and Microsoft are all making this change, it's just that we're hitting the problems first.

For testing, people can use --disable-ssl-false-start (which is an unfortunately named and repurposed option) to switch it off, at least in current releases.

Automatic fallbacks have a history of creating long-term problems for everybody and we are very much opposed to them.
Comment 26 by ste...@konink.de, Oct 27 2011
So the biggest open source webserver doesn't support it. Cherokee doesn't support it. Nginx did. 

It sounds Chrome was tested extensively after pushing this. If you want to make the web better (and faster), at least create a ticket in the bugtracker of the servers that you see fail after this change. Now users come with odd questions about SSL failing.

And yes: Chrome (not webkit) had weird SSL behavior in the past too. It annoys me very much there is absolutely no communication.
Comment 27 by agl@chromium.org, Oct 27 2011
The biggest open source webserver is Apache, no? I've not heard of any problems with Apache.

A ticket with Cherokee was opened by the user who reported the issue to us.

lighttpd had a problem with some older versions, but several fixed versions had been released since then.

There are a couple of non-open source stacks with issues and I've been spending a lot of time dealing those vendors.

I'm afraid that there isn't any comprehensive test suite for HTTPS servers, although making one from our internal production tests has been on my wish list for a while. Prior to making this change, Opera had run a scan over public sites to gauge level of problems, but that only tested GETing '/' and would have missed many of these problems.

This was a rather nasty change due to the possibility of breaking higher up the stack than the SSL library itself but mistakes have been made with HTTPS and, where feasible, we (meaning all browsers) need to slowly try and ameliorate them. I'm afraid that Chrome usually hits these things first because we tend to update faster.
Comment 28 by ste...@konink.de, Oct 27 2011
Apache based authentication plugin mentioned in comment 4 made me wonder if that was Apache or third party. Sadly this 'problem' was reported before there was a remote indication of being related to the 'cutting', it was a pure hunch after remembering a slashdot article on the BEAST exploit.

A test suite starts to sound as really required. Q/A testing of this type of low level things, are absolutely required.

Regarding 'attacks'... since we all read the news on SSL flooding in last couple of days, deny of service is probably an other thing that is getting easier and easier.
Comment 29 by djm...@gmail.com, Oct 27 2011
I can confirm that our problem outlined in comment #4 ( apache based authentication plugin ) was indeed a third party plugin. The problem was NOT with Apache ( 2.2.11 and newer at least ). Apache was handling the request just fine. This was our custom plugin code that was not expecting the post request to be broken up. 

I would expect most of the problems encountered with this change are not due to the actual web server itself, rather frameworks/plugins running on top of them. 
Comment 30 by enwuk...@gmail.com, Jan 16 2012
Confirming the bug on:

- 18.0.1003.1 dev - Linux
- 18.0.1003.1 dev-m - Windows

The bug does not appear on:

- 16.0.912.75 on Windows

Separate computers and users were used for the test. ;)


The server:

# lighttpd -v       
lighttpd/1.4.26 (ssl) - a light and fast webserver
Build-Date: Dec 20 2011 14:47:02

Ubuntu 11.10 (oneiric) package version: 1.4.26-1.1ubuntu3.1
Comment 31 by agl@chromium.org, Jan 16 2012
enwukaer: lighttpd 1.4.26 is buggy see http://redmine.lighttpd.net/issues/2197

1.4.27 was released to fix it.
Project Member Comment 32 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-Internals -Internals-Network-SSL Cr-Internals Cr-Internals-Network-SSL
Status: Archived
Archiving unconfirmed issues, which have not been modified (commented on, updated, etc...) in over 2 years.
Sign in to add a comment