Closed Bug 276813 Opened 20 years ago Closed 8 years ago

[RFE] Support RFC 2817 / TLS Upgrade for HTTP 1.1

Categories

(Core :: Networking: HTTP, enhancement)

Product:
Core
Component:
Networking: HTTP
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: pquerna, Unassigned)

References

(
URL
)

Details

(Keywords: helpwanted) 

This is a request for Mozilla to support TLS Upgrades inside HTTP 1.1 as
specified in RFC 2817.

RFC 2817 is currently supported in the Apache HTTPD 2.1 Development branch. 
Several other less popular servers also support it.
CC'ing folks with opinions on this proposal.  
I believe this is very important, as it allows for support for virtual hosting
SSL connections.  I'd be willing to look at writing the patch myself if someone
can point me in the right direction.
Keywords: helpwanted
Target Milestone: --- → Future
I can provide an Apache HTTPD 2.1 server with TLS upgrade enabled, if anyone needs it to test.
If the goal is virtual SSL hosting, the right way to do that is NOT
http ugprade but rather TLS "server name indication".  See RFC 3546.

One of the numerous problems with http upgrade is that there is no 
way to tell the browser that "this connection MUST upgade to TLS or 
the transaction must not be performed."  

TLS server name indication facilitates virtual serving while continuing
to use https://, which mandates the use of TLS (SSL 3.1)
TLS Name indication is an entirely different subject.

"this connection MUST upgade to TLS or the transaction must not be performed."

Server Sends a 101 Upgrade?

For the client to indicate it must upgrade, its just a user interface question.  How should it be presented 
to the user?  One idea is to use another URL scheme, but I am sure some people would not like this.
To restate the issue, there's no way for an http page writer to specify an
http link (e.g. form post action) that tells the browser to REQUIRE that 
the connection for that post MUST upgrade or fail.   There is no way for
the writer of a page that does form post to http to offer any assurance to
the user that the form post will be secure.  The browser has no way of 
knowing whether or not it should care (and notify the user) if the site
does not upgrade  (and most sites won't).

The https protocol takes care of all that already.  Virtual https hosting 
can be accomplished through server name indication.
Paul,

The TLS upgrade was designed for some specific applications such as the Internet
Printing Protocol, not for general browser and server use. I wrote the opinion
below 4 years ago from a web server implementer's point of view, but I object to
it equally to its use in a web browser, as an appropriate URL scheme has not
been created for TLS upgrade, and I consider the http:// URL scheme to be
inappropriate for its use.

<start QUOTE>
The main problem with TLS upgrade is that there is no URL scheme defined to tell
which objects are secure and non-secure.
The proposed URL scheme for http with TLS upgrade is the regular "http://" used
for non secure content, and when to the negotiation is left undetermined.
The result is that if you have both upgrade-compatible clients and servers, all
connections will be secure. If either side is not upgrade-compatible, they are
all insecure. Neither case is desirable. Security has significant performance on
servers, and it is desirable to be able to set which portions of your site are
secure and which are not. Most content doesn't need to be secure and you don't
want it to be, unless you have the money for spare hardware to handle it. Even
then, the user's experience will generally be a bit slower. No security is
obviously not acceptable for some content.

Some will argue that it is possible to resolve this secure/non-secure control by
setting ACLs on the server and configuring which parts require security. But
this means a lot more work on the part of the server administrator to determine
this. It is infinitely easier to simply set the "https://" URL scheme on the
pages that require security, as it is done today without TLS upgrade.
Unfortunately the SSL/TLS protocol specified with "https://" is not directly
compatible with the TLS upgrade scheme, since it doesn't have an initial
insecure handshake. When specifying https:// in a client, it is expected that
the SSL/TLS handshake will occur at the first I/O operation, but that is not
true with TLS upgrade.

In addition, the URL scheme can be quite a headache to manage this with dynamic
content as well, since "http://" has to be specified in all dynamic pages. It
would then be up to each individual application to check security in its URI
space for each request !!!

Because of this, I think the TLS upgrade scheme proposed is inherently flawed
and not workable for general-purpose web applications. I discussed this in
detail on the HTTP working group mailing list. The author admitted that he
created it specifically for use with the "internet printing applications" and
that it was never intended for general use in web clients and servers.

I think the problem could be easily resolved simply by adding a new URL scheme
(such as httpt:// ) which would mean to the client : send the host header to
this server with HTTP, then upgrade the connection to TLS and proceed with the
request securely, in much of the fashion as with https (same
protocols/ciphers/etc). This would resolve the huge ambiguity that exists today
in the proposed TLS upgrade scheme.
<end QUOTE>

Fortunately, TLS upgrade isn't the only game in town to do name-based SSL
virtual servers. The TLS server name indication has also been standardized and
it is a sound approach, as it properly uses the https:// URL scheme which
enforces an ensuing SSL handshake and doesn't have the risk of data possibly
going out in the clear accidentally.

I strongly recommend that this bug be marked WONTFIX.

Cool, if Bug 116168 is the better solution, I'll try and work on that instead.
It's not clear to me why a separate URI protocol scheme is necessary here.  The assertion that page authors have no way of specifying that TLS is required also seems unfounded to me.

Both user agent and server advertise support for TLS through the Upgrade header.  RFC2817 clearly spells out the following scenarios:

1. A user agent demanding a secured connection for a given request
2. A user agent requesting (but not requiring) a secured connection
3. A server demanding a secured connection for a client's request
4. A server indicating that TLS is available if the client desires

A logical site may have a URL hierarchy like this:

/press-releases
/support
/orders

The server could be configured like this:

1. TLS is optional for /press-releases and /support
2. TLS is required for /orders

The user agent could work like this:

1. Requests for /press-releases are retrieved without security.
2. Requests or POSTs to /orders would see the 426 response code and switch over to TLS for the request without any additional user interaction
3. A POST to /support may throw up a dialog box (maybe 'remember this' on a per-URL basis) telling the user that TLS is available if they'd prefer to make this submission securely.

In other words, the RFC seems to consider all of the possible scenarios where the HTTP requests/response would want to be secured, and it seems clear how the server can inform the client that TLS is available or required.  It's up to the user agent to come up with reasonable UI to deal with these scenarios.

The browser could also have persistent settings such as "Always use TLS when TLS is advertised".  I see no reason for this to be WONTFIX.  In fact, it seems like a useful feature.  
David,

Take your example #3 :

3. A POST to /support may throw up a dialog box (maybe 'remember this' on a
per-URL basis) telling the user that TLS is available if they'd prefer to make
this submission securely.

The problem is in the possibily, the "if" question.
Do you suggest that the client will throw this dialog for every POST with the http:// method, to ask if they want to submit securely ?
This will get old for most users . And I'm speaking as someone who has the pop-up warning for "sending form data from an encrypted page to an encrypted page" enabled.

Also, what if the TLS upgrade negotiation fails - for example, because the server does not support it, as in 99% of the cases; or because there was a man-in-the-middle attacker which intercepted the response and claimed the server didn't support it ? Does the browser then just not submit ? Or does he submit without TLS upgrade ?

Without a proper URL scheme in the form submit indicating that security is required, there is no way for the browser to know how to enforce it.

I'm not the only one of the opinion that RFC2817 is broken.

See http://jis.mit.edu/pipermail/saag/2001q4/000253.html . This is a post by Eric Rescorla, author of "SSL and TLS : Designing and Building Secure Systems".

My main objection is 2b) on grounds of security. 1) - the proxy issue is also a big problem . I would live with 2a) - the performance issue - if the other 2 problems were fixed.
Assignee: darin → nobody
Until (X)HTML forms / XForms incorporates either an attribute or some algorithim for indicating when the client should demand security (for example, always demand when the page the form is on came encrypted, etc.), I do believe content authors will still need to use the https URI scheme. In the meantime, however, I think it might be wise to separate this issue into two separate cases:

(1) Mozilla navigates to a http prefixed URI and the server sends a mandatory upgrade header.

(2) All other permutations in RFC 2817.

I think we should support case (1). Although the previous commentators make valid points about the continued utility of the https URI scheme, allowing the server to demand mandatory in-connection upgrade also has utility. Today, when a client makes a clear-text request to a protected resource, servers usually send a 3xx redirect to the same resource location but with the https protocol prefix.  Although this response gets the job done, it doesn't really jive with the meaning of the status code. It would be appropriate in this case for the server to demand an upgrade to TLS within the same connection. I have doubts about how widely this will be implimented, and I'm not really sure that it's worth someone volunteering their time to code. But if someone really wants to contribute it, I say go ahead.
I understand the doubts that people had with TLS upgrade above. (That you cannot indicate in a link, that TLS upgrade should be required.)
But I want to throw in, that this should not prevent RFC 2817 from being implemented. TLS upgrade uses http URI, which are otherwise completely unprotected. Therefore this standard does not introduce additional weakness to otherwise unproctected transmitted form (or other) data, but allows this data being optionally protected.
If a link needs to be transmitted over a protected connection, https can still be used.
I aggree with Matthias Wimmer (Comment #12) and Dan Culley (Comment #11):
If someone is willing to implement the case of a server demanding a Upgrade to TLS for some ressource, supporting this upgrade wouldn't only secura a potentially insecure connection, but not supporting this upgrade may keep Mozilla software users from accessing this ressource at all if it is not accessible via some https:// URI.

For example a web interface like the one CUPS is providing on its IPP port could secure the ressources which need authentication while providing unencrypted access to printer queues and public information on only one port.

I've got a modified version of the https:// that basically works like this:
1. Try to connect using RFC 2817.
2. Otherwise, on "normal" errors, try to connect to 443.

It's working successfully with Apache 2.2.6 and Cups. There's at least one server, however, that doesn't play nice with OPTIONS (no "normal" errors). I don't know yet whether I'll add a workaround or make some sort of site-override preference.

If there's any interest from Mozilla in integrating this feature, please let me know.
I can't speak for Mozilla, but I personally am interested in seeing it.

I'm also still interested in seeing support for the optional upgrade.  If I had a checkbox for "Use TLS when TLS support is advertised", I'd check it, even if the data isn't absolutely confidential.  *I* have the CPU cycles to spare (as a client), and if the host is willing to spare them, I'd like to take advantage of that.

One other thing I thought about with two URL paths that have different TLS requirements is that this feature allows you to change what parts of your site need to be protected without changing the URL.
I've improved that modified https: behavior. However, the work's gonna be frozen because, although Apache supports TLS upgrades, it doesn't support certificate selection. Without server-side support for name based hosting, there's little point in going on with this.
(In reply to comment #14)
> For example a web interface like the one CUPS is providing on its IPP port
> could secure the ressources which need authentication while providing
> unencrypted access to printer queues and public information on only one port.

CUPS accepts both HTTP upgrades and TLS connections on the very same port. Because no server requires upgrades, I see no reason to ever support RFC 2817 (my code's permanently canceled).
I strongly recommend marking this RFE as WONTFIX.

I think it would be inappropriate to mark this as WONTFIX, unless there are significant obstacles to implementing it. As long as the browser UI doesn't impart a potentially false sense of security by e.g. displaying the lock icon, and as long as server administrators don't use it as a substitute for https://, I don't see any problem with supporting it.

In fact, the browser should even be able to upgrade with a self-signed server cert without prompting the user. Sites and users that expect a guaranteed higher level of security than http:// currently provides can use https:// URIs, just like they do now.


> as long as server administrators don't use it as a substitute for https://,
> I don't see any problem with supporting it.

Server admins, and more importantly, html and Javascript coders, absolutely
WILL use it as a substitute for https, and the browser will not be able to 
detect or prevent the error.  User's are very slow to notice that the lock
icon is NOT displayed when it should be.  Users generally are slow to discover
that something is missing from the UI "chrome".  

The biggest problem is that web page coders will code http (instead of https) into their links and form actions, expecting and believing that it will "upgrade" because they expect it to do so.  But http upgrade is trivially defeated by an attacker.  It is very simple for an attacker to prevent an upgrade from occurring and to do so in a way that is undetectable by the brwoser or server.  The attacker defeats the upgrade, even though the page
coder was relying on it succeeding.  

So we must conclude that http upgrade is unreliable.  You cannot rely on it
working when you needing.  Consequently, it is only security for when you 
don't really need it.  But naive page coders will continue to use it (if 
they can) and expect that it is reliable.  It will give THEM the false sense
of security.

In the spectrum of security work, ranging from important to unimportant, 
doing security work that is unreliable is the least important.  
What has always surprised me as a web application developer is that there is nothing in between insecure and secure/trusted. As SSL goes the extra step of also imposing trust. Though having the ability to verify the server is good. As it prevents phishing. It is irrelevant to go the extra step of having to impose trust by a CA. Most web applications already knowns its users and the users get credentials assigned to them by an existing user.

The TLS/upgrade feature could fill the gap in allowing a response by the server to upgrade to a secure connection and resend the request with credentials over the secured connections. In these scenario's a lock icon is nice but other visual cues should be reserved for the https scheme. In this way the https scheme is reserved for those web sites/applications where trust is important. Forcing strict trust rules as they now apply. For the http scheme which is thought off as untrusted anyway these strict rules could be relaxed. Displaying no errors about mixed secure and unsecure resources and no errors about self-signed certificates. Thus allowing web application developers to make use of TLS without having to pay for certificates when only a secure connection is desirable to enhance security.

I vote that the TLS/upgrade feature get implemented but only as a means to secure the connection for authentication using either client certificates (self-signed or signed by the company hosting the application) or HTTP basic authentication and not as an alternative to the https scheme with the extra trust features and visual cues.

BTW Apache 2.2 now fully supports the TLS/upgrade feature making it relevant again.
This will be kind-of obsoleted by WebSockets?
No a WebSockets upgrade is initiated by the client not the server. Also WebSockets do not switch from unsecure to secure. See section 1.7 of http://www.whatwg.org/specs/web-socket-protocol/

The hole point about the TLS Upgrade is not to have a full https server. But just a plain http server with the option to force the user agent to upgrade to a TLS connection on the http port. (I would reckon a WebSockets connection would also be upgraded in such an event.) Right now you have to setup both a http and https server and redirect the user agent to the https server when a secure channel is required.
When the preferred method of authentication is a simple login screen thus not using certificates for authentication. It seems a bit silly to be forced to have both a http and https server. If you aren't going to use the trust system provided by the certificates anyways.
The only reason I actually have setup https server with a real certificate is to not bother my users with warnings about an untrusted host. Personally however I don't see the benefit of certificates in web applications when administrators controls who gets to login and who not using plain simple login screens. But maybe someone can explain it to my one day.
Even if the actual upgrade process described in the RFC isn't implemented, would it hurt to add a heuristic to attempt to switch to HTTPS on port 443 in the event of receiving a status 426 from the server? It seems like this would accomplish what the user expects an overwhelming portion of the time and web servers are increasingly using this response when an area is closed to non-secure access (e.g. Cherokee).
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
(In reply to Ben Gamari from comment #25)
> Even if the actual upgrade process described in the RFC isn't implemented,
> would it hurt to add a heuristic to attempt to switch to HTTPS on port 443
> in the event of receiving a status 426 from the server? It seems like this
> would accomplish what the user expects an overwhelming portion of the time
> and web servers are increasingly using this response when an area is closed
> to non-secure access (e.g. Cherokee).

Yes, it would hurt, as an MITM attacker can intercept the 426 error code from the server and interpose itself in the traffic - talking to the client over plaintext HTTP, and to the server over HTTPS.
Neither side would be aware of the MITM in this situation.
You need to log in before you can comment on or make changes to this bug.