Andreas Sterbenz wrote:
>
> Maybe I have a somewhat simplistic view of the issue not having read any
> of those papers
In
http://www.cs.berkeley.edu/~daw/classes/cs261/projects/final-reports/ronathan-heyning.ps
you can see an attack.
In http://www.counterpane.com you can find the "Analysis of the SSL 3.0
protocol"
TLS...you know
> but would the obvious solution not be to add dummy
> headers to the HTTP request/response?
Padding is part of the solution, however, an attacker can guess what
page you download making statistical inferences using the content
lengths, number of connections, and correlations with the last, this and
next page accessed. That is accomplished (from my point of view) by
adding dummy connections (and encapsulating more than one request in a
SSL connection) thus breaking the mapping among the http messages and
SSL connections.
> For example, the client could add an "X-Pad: datadatadatadata" header
> with random length data to the request discouraging URL guessing based on
> the request message length. The server could do the same for the
> response. The big plus is that this is perfectly downwards compatible.
I'm not a big HTTP guru, but when you say downwards compatible, you mean
that when a client (that supports this extension) adding a header with
"X-Pad: datadatadatadata" in the request, a regular HTTP 1.1 server (ie
witch not know what X-Pad is) STILL will ignore it and the resource will
be served in the regular way? Could you help me with that?
> A
> minus is that you can of course only increase the length of messages this
> way, but my understanding of HTTP/1.1 is that you could work around that
> by making several requests and using ranges.
Ranges are not meant for complete cached fragments of a resource when a
transfer is interrupted? Will this double pourpose use of ranges
complicate the HTTP implementation, just for breaking the mapping of the
HTTP connections with the SSL connections?
I believe that implementing this mapping in a separate protocol, then
somebody could use it for any other application protocol someday. By
embeedding this behavior in the app protocol, we are not doing any
knowledge reuse, and we are scrambling app protocol functionality with
common basic security services. I agree that traffic analysis is not too
much a concern now on Internet but you know...today's solutions are
tomorrow's problems!
> As an only partially related note, TLS explicitly allows any apropriate
> padding length from 0-255 for block ciphers exactly to avoid attacks
> based on message lengths at the record level.
That's right. Also, TLS does NOT provides random padding length from
0-255 for stream ciphers.
I can't imagine a message in a web site saying:
"If you want to avoid traffic analysis attacks, then you must go to the
Security screen in your Netscape Navigator and disable the CipherSuites
using stream ciphers. Warning: Don't use IE because you can't disable
stream ciphers."
Users don't care about block or stream ciphers (specially the kind of
high-level-strategic-business users that may want to avoid those
attacks).
TLS should provide that kind of service to stream ciphers!
Again, padding alone is not the end of the history.
Cheers,
Gabriel
> Regards,
>
> Andreas Sterbenz mailto:[EMAIL PROTECTED]
>
> -----Ursprüngliche Nachricht-----
> Von: Gabriel Belingueres <[EMAIL PROTECTED]>
> An: <[EMAIL PROTECTED]>
> Gesendet: Montag, 06. September 1999 18:18
> Betreff: Re: Web Traffic Analysis
>
> > Here I send to you a draft of the protocol, but there are a lot of work
> > to do yet.
> > Numbers and lengths are drafts too.
> >
> > Gabriel.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
