Browser Support for TLS/HTTP Upgrade?

2000-12-20 Thread Michael Sweet 

Hi, All!

We're about to release a TLS/SSL-capable version of CUPS (1.1.5)
that uses OpenSSL.  So far everything is working great (so far not
a single glitch I can see with 0.9.6!), but we're struggling with
one final issue...

CUPS 1.1.5 supports both dedicated TLS/SSL connections (https
scheme) as well as the HTTP Upgrade mechanism for upgrading to
TLS/SSL.  Both methods work perfectly with the CUPS client apps,
but web browsers (so far) seem only to support https connections.
In the case of Netscape 4.x, it also only works on port 443 (if you
specify a port with the https: scheme then it tries to lookup the
hostname with the :port stuff tacked on...)

Are there any web browsers out there that support the HTTP Upgrade
spec to upgrade to TLS/SSL? (so far I've only had a chance to try
Netscape 4.x and MSIE 5.0 and 5.5)

We're also looking at auto-detecting the client hello message when
a client connects (if the first byte coming over the wire is 1, do
the TLS/SSL negotiation...)  Given that Netscape (the most likely
browser under UNIX) doesn't support the port number notation in
https: URLS, I'm not sure if this will buy us anything, but might
allow the IPP port (631) to pull triple-duty (unencrypted,
dedicated, and upgrade connections) on systems that already have
a secure web server running on port 443.

Does anyone see any problems with this kind of auto-detection
I'm thinking more along the lines of security/reliability
problems; am I safe in assuming that OpenSSL can reject a
bad or malformed client hello message?

TIA!

-- 
__
Michael Sweet, Easy Software Products  [EMAIL PROTECTED]
Printing Software for UNIX   http://www.easysw.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Browser Support for TLS/HTTP Upgrade?

2000-12-20 Thread Lutz Jaenicke 

On Wed, Dec 20, 2000 at 10:32:59AM -0500, Michael Sweet wrote:
> CUPS 1.1.5 supports both dedicated TLS/SSL connections (https
> scheme) as well as the HTTP Upgrade mechanism for upgrading to
> TLS/SSL.  Both methods work perfectly with the CUPS client apps,
> but web browsers (so far) seem only to support https connections.
> In the case of Netscape 4.x, it also only works on port 443 (if you
> specify a port with the https: scheme then it tries to lookup the
> hostname with the :port stuff tacked on...)

I have not tried the Windows version, only the HP-UX one, but it always
worked as expected.
  perform an "openssl s_server -www" on 'some.host' within openssl-*/apps
  (there are the necessary certificates readily available :-)
  On another host ask netscape to contact 'https://some.host:4433/'
Works for me.

> Are there any web browsers out there that support the HTTP Upgrade
> spec to upgrade to TLS/SSL? (so far I've only had a chance to try
> Netscape 4.x and MSIE 5.0 and 5.5)

As far as I know there has no browser been released using this technique.
Maybe somebody knows better than me :-)

Best regards,
Lutz
-- 
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus   http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus  Fax. +49 355 69-4153
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Browser Support for TLS/HTTP Upgrade?

2000-12-20 Thread Eric Rescorla 

Lutz Jaenicke <[EMAIL PROTECTED]> writes:
> > Are there any web browsers out there that support the HTTP Upgrade
> > spec to upgrade to TLS/SSL? (so far I've only had a chance to try
> > Netscape 4.x and MSIE 5.0 and 5.5)
> 
> As far as I know there has no browser been released using this technique.
> Maybe somebody knows better than me :-)
Not as far as I know. It was never really expected that this technique
would replace HTTPs for web pages, only for other HTTP/TLS uses.
(Though frankly I doubt that as well.)

-Ekr

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Browser Support for TLS/HTTP Upgrade?

2000-12-20 Thread Michael Sweet 

Eric Rescorla wrote:
> ...
> Not as far as I know. It was never really expected that this
> technique would replace HTTPs for web pages, only for other
> HTTP/TLS uses. (Though frankly I doubt that as well.)

It's the only recognized way of doing encryption for IPP... :(

-- 
__
Michael Sweet, Easy Software Products  [EMAIL PROTECTED]
Printing Software for UNIX   http://www.easysw.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Browser Support for TLS/HTTP Upgrade?

2000-12-20 Thread Richard Levitte - VMS Whacker 

From: Eric Rescorla <[EMAIL PROTECTED]>

ekr> Not as far as I know. It was never really expected that this
ekr> technique would replace HTTPs for web pages, only for other
ekr> HTTP/TLS uses.  (Though frankly I doubt that as well.)

Uhmm, what exactly is the functional difference between HTTPS and
HTTP/TLS?  For me, they describe the function "running HTTP through a
SSL or TLS encryption tunnel"...

I think the matter is of deployment and laziness to some level.  After
all, RFC2817 isn't even a year old, and it does take time before an
RFC generates some real stuff (look at RFC2560 which is a year and a
half old, it took time before there were OCSP-aware products)...

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken   \ S-168 35  BROMMA  \ T: +46-8-26 52 47
Redakteur@Stacken   \  SWEDEN   \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Browser Support for TLS/HTTP Upgrade?

2000-12-20 Thread Eric Rescorla 

Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> writes:

> From: Eric Rescorla <[EMAIL PROTECTED]>
> 
> ekr> Not as far as I know. It was never really expected that this
> ekr> technique would replace HTTPs for web pages, only for other
> ekr> HTTP/TLS uses.  (Though frankly I doubt that as well.)
> 
> Uhmm, what exactly is the functional difference between HTTPS and
> HTTP/TLS?  For me, they describe the function "running HTTP through a
> SSL or TLS encryption tunnel"...
Well, my usage is that HTTP/TLS is the generic term for any use
of HTTP over TLS. HTTPS refers to the traditional usage of
HTTP over SSL/TLS as described in RFC 2818. I use HTTP Upgrade to
refer to the protocol described in RFC 2817.

> I think the matter is of deployment and laziness to some level.  After
> all, RFC2817 isn't even a year old, and it does take time before an
> RFC generates some real stuff (look at RFC2560 which is a year and a
> half old, it took time before there were OCSP-aware products)...
I don't think it's just laziness.

Frankly, RFC 2817 has a lot of problems. Although it allows
automatic negotiation, which is a plus, there's no way to
specify in the URL that the client should EXPECT to negotiation
TLS (other than using https:// which would indicate that you
should do HTTPS, not HTTP Upgrade with a requirement for TLS).
This is a serious reference integrity problem.

Also, HTTP Upgrade interacts very badly with proxies. Since
Upgrade is a hop-by-hop header, there's no way to negotiate
an end-to-end HTTP Upgrade to TLS through a proxy, which is
a serious problem. By contrast, HTTPS just uses the CONNECT
method.

So, I don't expect HTTP Upgrade to displace HTTPS for web
browsers any time soon.

-Ekr

[Eric Rescorla   [EMAIL PROTECTED]]
Author of "SSL and TLS: Designing and Building Secure Systems"
   http://www.rtfm.com/
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Browser Support for TLS/HTTP Upgrade?

2000-12-20 Thread Michael Sweet 

Richard Levitte - VMS Whacker wrote:
> ...
> Uhmm, what exactly is the functional difference between HTTPS and
> HTTP/TLS?  For me, they describe the function "running HTTP
> through a SSL or TLS encryption tunnel"...

The https scheme defines a secure connection (default port 443)
for HTTP.  The encryption is mandatory and immediate.

The "HTTP Upgrade" spec defines a new HTTP status code (426)
and the necessary fields and values needed to upgrade an
existing HTTP link (on port 80 or whatever) to an encrypted
one.  The client or server can initiate the upgrade.  Once
you start the HTTP upgrade, the handshake is the same as
for SSL or TLS.

The driving force behind the HTTP Upgrade specification was
to get away from each protocol defining a secure and non-
secure port.  Any new IETF-approved protocol that supports
encryption must now do it through an "upgrade" process -
you can't use two different ports anymore...

The upgrade method also has the added benefit of supporting
new technologies more easily - e.g. Kerberos over HTTP.
A HTTP client or server app can provide modules for all of
the encryption support - new module, new upgrade method.

-- 
__
Michael Sweet, Easy Software Products  [EMAIL PROTECTED]
Printing Software for UNIX   http://www.easysw.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Browser Support for TLS/HTTP Upgrade?

2000-12-20 Thread Jeffrey Altman 

> The upgrade method also has the added benefit of supporting
> new technologies more easily - e.g. Kerberos over HTTP.
> A HTTP client or server app can provide modules for all of
> the encryption support - new module, new upgrade method.

I would hope that anyone interested in implementing Kerberos
in HTTP do so by using the TLS Kerberos cipher suites.



 Jeffrey Altman * Sr.Software Designer  C-Kermit 7.1 Alpha available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/ using Kerberos, SRP, and 
 [EMAIL PROTECTED]  OpenSSL.  SSH soon to follow.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Browser Support for TLS/HTTP Upgrade?

2000-12-20 Thread Michael Sweet 

Jeffrey Altman wrote:
> ...
> I would hope that anyone interested in implementing Kerberos
> in HTTP do so by using the TLS Kerberos cipher suites.

OK, bad example.  Maybe AES (Rjidahl or however you spell it :)
then?

In any case, it's an attempt to allow for more than one encryption
protocol to be used over HTTP without requiring additional ports.

-- 
__
Michael Sweet, Easy Software Products  [EMAIL PROTECTED]
Printing Software for UNIX   http://www.easysw.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Browser Support for TLS/HTTP Upgrade?

2000-12-20 Thread Jeffrey Altman 

> Jeffrey Altman wrote:
> > ...
> > I would hope that anyone interested in implementing Kerberos
> > in HTTP do so by using the TLS Kerberos cipher suites.
> 
> OK, bad example.  Maybe AES (Rjidahl or however you spell it :)
> then?

This is a bad example as well.  The idea is not to allow additional 
encryption algorithms to be used.  Encryption algorithms, key exchange
algorithms, integrity protection, compression are all things that need
to be integrated into a secure transport protocol.  That protocol is
TLS. 
 
> In any case, it's an attempt to allow for more than one encryption
> protocol to be used over HTTP without requiring additional ports.

Secure transport protocols are extremely hard to get right.  We
certainly do not need anything other than TLS.  Anything else would be
a tremendous waste of effort.




 Jeffrey Altman * Sr.Software Designer  C-Kermit 7.1 Alpha available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/ using Kerberos, SRP, and 
 [EMAIL PROTECTED]  OpenSSL.  SSH soon to follow.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Browser Support for TLS/HTTP Upgrade?

2000-12-20 Thread Richard Levitte - VMS Whacker 

From: Eric Rescorla <[EMAIL PROTECTED]>

ekr> Frankly, RFC 2817 has a lot of problems. Although it allows
ekr> automatic negotiation, which is a plus, there's no way to
ekr> specify in the URL that the client should EXPECT to negotiation
ekr> TLS (other than using https:// which would indicate that you
ekr> should do HTTPS, not HTTP Upgrade with a requirement for TLS).
ekr> This is a serious reference integrity problem.

That is a very good point.

ekr> Also, HTTP Upgrade interacts very badly with proxies. Since
ekr> Upgrade is a hop-by-hop header, there's no way to negotiate
ekr> an end-to-end HTTP Upgrade to TLS through a proxy, which is
ekr> a serious problem. By contrast, HTTPS just uses the CONNECT
ekr> method.

Uhmm, what would stop any client to connect to the proxy, say CONNECT
to it, and after getting the 200 back do the HTTP Upgrade through that
channel?

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken   \ S-168 35  BROMMA  \ T: +46-8-26 52 47
Redakteur@Stacken   \  SWEDEN   \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Browser Support for TLS/HTTP Upgrade?

2000-12-20 Thread Richard Levitte - VMS Whacker 

From: Michael Sweet <[EMAIL PROTECTED]>

mike> The "HTTP Upgrade" spec defines a new HTTP status code (426)
mike> and the necessary fields and values needed to upgrade an
mike> existing HTTP link (on port 80 or whatever) to an encrypted
mike> one.  The client or server can initiate the upgrade.  Once
mike> you start the HTTP upgrade, the handshake is the same as
mike> for SSL or TLS.

I think Eric's point is one of user request and feedback.  How does a
user easily request a secure channel?  As it is right now, "https:" as
opposed to "http:" is a very simple way, and also contains direct
feedback.  The user knows (hopefully) that the extra "s" means it's
intended to be secure (at least, we can hope for it, can't we?  :-)).

Of course, on graphical browsers, there's normally some other way to
get the feedback as well...

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken   \ S-168 35  BROMMA  \ T: +46-8-26 52 47
Redakteur@Stacken   \  SWEDEN   \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Browser Support for TLS/HTTP Upgrade?

2000-12-20 Thread Michael Sweet 

Richard Levitte - VMS Whacker wrote:
> ...
> I think Eric's point is one of user request and feedback.  How
> does a user easily request a secure channel?  As it is right now,
> "https:" as opposed to "http:" is a very simple way, and also
> contains direct feedback.  The user knows (hopefully) that the
> extra "s" means it's intended to be secure (at least, we can hope
> for it, can't we?  :-)).

:)

I'd imagine that many products would follow the lead of Netscape
and MS with a separate checkbox, as is already available for EMail
and news servers.

In our software (CUPS and Print Pro) the user can force
encryption via config files or environment variables (crude, but
sufficient for now while we work out the functional requirements)
I anticipate we'll be adding a command-line option to force
encryption (e.g. "lpr -E" or something like that), with similar
options in the GUIs.



That said, I don't think HTTP Upgrade will replace https.  They
each have their places - I just hope that browsers start
supporting HTTP Upgrade (at least the server-initiated kind)
so that we don't have to write a hack-and-a-half to work around
browser limitations...

-- 
__
Michael Sweet, Easy Software Products  [EMAIL PROTECTED]
Printing Software for UNIX   http://www.easysw.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Browser Support for TLS/HTTP Upgrade?

2000-12-20 Thread Eric Rescorla 

Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> writes:
> From: Eric Rescorla <[EMAIL PROTECTED]>
> ekr> Also, HTTP Upgrade interacts very badly with proxies. Since
> ekr> Upgrade is a hop-by-hop header, there's no way to negotiate
> ekr> an end-to-end HTTP Upgrade to TLS through a proxy, which is
> ekr> a serious problem. By contrast, HTTPS just uses the CONNECT
> ekr> method.
> 
> Uhmm, what would stop any client to connect to the proxy, say CONNECT
> to it, and after getting the 200 back do the HTTP Upgrade through that
> channel?
Nothing. However, think about the consequences of this. Since you
have no idea whether a given server will support upgrade to TLS
you want to take advantage of it whenever it's available, right?
But in order to do so you've got to always use CONNECT and then
offer Upgrade. But this removes any possibility that the proxy
might cache your request (unless it violates the semantics of
the CONNECT), which seriously degrades the usefulness of the proxy
in many environments.

I suppose you could have a more sophisticated client which only
offered Upgrade when you were dereferencing a form or something,
but this still runs the risk that some confidential information
might leak (e.g. with basic authentication over HTTP) or when
the URL itself is secret.

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]]
http://www.rtfm.com/
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Browser Support for TLS/HTTP Upgrade?

2000-12-20 Thread Eric Rescorla 

Michael Sweet <[EMAIL PROTECTED]> writes:

> Richard Levitte - VMS Whacker wrote:
> > ...
> > I think Eric's point is one of user request and feedback.  How
> > does a user easily request a secure channel?  As it is right now,
> > "https:" as opposed to "http:" is a very simple way, and also
> > contains direct feedback.  The user knows (hopefully) that the
> > extra "s" means it's intended to be secure (at least, we can hope
> > for it, can't we?  :-)).
> 
> :)
> 
> I'd imagine that many products would follow the lead of Netscape
> and MS with a separate checkbox, as is already available for EMail
> and news servers.
>
> In our software (CUPS and Print Pro) the user can force
> encryption via config files or environment variables (crude, but
> sufficient for now while we work out the functional requirements)
> I anticipate we'll be adding a command-line option to force
> encryption (e.g. "lpr -E" or something like that), with similar
> options in the GUIs.
The reason that this sort of thing works for mail and news is
that to a first order you're always talking to the same server
(your first hop server). The problem is that with HTTP you 
have to talk to a wide variety of servers, many of whom do
not support encryption. In such cases, requiring TLS tends
to result in not being able to connect to anyone.

What you really want is some way for the server to tell you
that TLS is required and then the client can insist on it.
"https://" serves this purpose but HTTP upgrade has no corresponding
signal.

> That said, I don't think HTTP Upgrade will replace https.  They
> each have their places - I just hope that browsers start
> supporting HTTP Upgrade (at least the server-initiated kind)
> so that we don't have to write a hack-and-a-half to work around
> browser limitations...
Unfortunately, in many situations the confidential information
is in the client's request. In such situations server upgrade
is of little value since the client has already transmitted
its confidential information by the time it knows it should upgrade.


-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]]
http://www.rtfm.com/
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]