400 Bad Request on Launchpad subdomains

Bug #823325 reported by Данило Шеган
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Invalid
Undecided
Unassigned
libsoup2.4 (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

With latest epiphany, fetching different subdomains of launchpad.net ends up with 400 Bad Request (not all the time, though). I was able to reproduce this with

$ openssl s_client -connect launchpad.net:443

...

GET / HTTP/1.1
Host: answers.launchpad.net

GET / HTTP/1.1
Host: bugs.launchpad.net

GET / HTTP/1.1
Host: code.launchpad.net

GET / HTTP/1.1
Host: translations.launchpad.net

which ended up with

HTTP/1.1 400 Bad Request
Date: Wed, 10 Aug 2011 09:43:19 GMT
Server: Apache/2.2.14 (Ubuntu)
Vary: Accept-Encoding
Content-Length: 306
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
<hr>
<address>Apache/2.2.14 (Ubuntu) Server at launchpad.net Port 443</address>
</body></html>

from two entirely distinct networks (so I hope that means that network configuration issues might not be the problem here).

Revision history for this message
Данило Шеган (danilo) wrote :

New upstream trunk exhibits the same problem, but there is no easy way to revert it anymore.

Revision history for this message
Данило Шеган (danilo) wrote :
Revision history for this message
Данило Шеган (danilo) wrote :

On more investigation, I could get this to fail using openssl directly with

openssl s_client -connect launchpad.net:443

and then pasting together

GET / HTTP/1.1
Host: answers.launchpad.net

GET / HTTP/1.1
Host: bugs.launchpad.net

GET / HTTP/1.1
Host: code.launchpad.net

GET / HTTP/1.1
Host: translations.launchpad.net

Changed in libsoup2.4 (Ubuntu):
status: New → Invalid
description: updated
summary: - 02_tls.patch breaks access to launchpad.net
+ 400 Bad Request on Launchpad subdomains
description: updated
Revision history for this message
Данило Шеган (danilo) wrote :

It seems the problem is reusing the same connection for different subdomains. I could very easily reproduce this with "gnutls-cli launchpad.net" and then requesting a different subdomain.

Changed in launchpad:
status: New → Incomplete
Changed in launchpad:
status: Incomplete → Invalid
Revision history for this message
Dan Winship (danw-gnome) wrote :

This is fixed with glib-networking master (and the next release, which I think will be 2.29.17). The patch should apply easily to earlier glib-networking releases as well. (http://git.gnome.org/browse/glib-networking/commit/?id=4175fd4718bfd247420fe20af492c944edf9b598)

FWIW, it seems to me that this is a bug in the server-side TLS implementation; the SNI should not be included as part of the saved session (since it's presented as part of the ClientHello, not in one of the messages that gets skipped when resuming), and even if it is saved, the server ought to refuse to resume the session if the SNI saved in the session doesn't match the SNI requested in the ClientHello. But I don't know exactly what bit of software would be responsible for that on the server side of launchpad.

Revision history for this message
Robert Collins (lifeless) wrote : Re: [Bug 823325] Re: 400 Bad Request on Launchpad subdomains

On Mon, Aug 29, 2011 at 5:06 AM, Dan Winship <email address hidden> wrote:
> know exactly what bit of software would be responsible for that on the
> server side of launchpad.

apache :)

-Rob

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.