Hi
> TLS defines random padding only when CipherSuites using block ciphers
> are agreed by the parties. If the CipherSuite chosen by the parties use
> a stream cipher, there is no random padding, so the length of the
> application layer data is bigger in a constant size, then there is no
> padding protection when stream ciphers are used in TLS.
Agree. The problem still occurs using stream ciphers.
> However, random padding of records are not the only thing to stop
> traffic analysis attacks. There is a lot of contextual data transmitted
> in a HTTPS request/reply.
> Using statistical methods, the attacker can guess the HTML file I'm
> viewing by keeping a record of the last, current and next page I will go
> (by clicking in a hiperlink).
> Also, both the quantity of TLS connections and lengths of the embedded
> resources into a HTML page (used with the HTML page length guessed) is
> usefull to accomplish the attack (if the browser cache is disabled), but
> although keeping the cache enabled is a common configuration in web
> browsing, it might not be in others application protocols, from there
> the idea of developing an extra layer below the app protocol and upper
> the TLS protocol, so that it is reusable by others applications, not
> only web browser and servers.
I see your point. I don't know whether you'll always have success
with traffic analysis using statistical methods. In my opinion this is
possible if the server only provides a few, completely different pages
(or other resources). There you can easily analyze the traffic.
But you'll have a problem to analyze the traffic if the server has a huge
amount of pages (or other resources). The problem to analyze the traffic
gets bigger if the pages are generated dynamically.
A real problem is the request of the browser. If you assume
that all the header variables are the same during several
requests you could analyze the GET request. As mentioned
in another mail, you could add some additional headers.
You might also send some OPTIONS * 'no-op' requests
to frustrate an attacker.
We have to consider where traffic analysis is useful to
gain relevant informations? You are welcome to complete
the list.
1. Backuping or transferring data from one biz to another biz?
What kind of information can you get with a traffic analysis?
You know that biz A transfered something to biz B. But you
have no idea what.
2. Doing internet banking?
Can you gain relevant information using statistical analysis?
You possibly find out that someone did a wired transfer. But
(if the system is designed well) you don't know who.
3. Doing shopping over the internet.
Can you gain relevant information using statistical analysis?
I know there are lots of other scenarios. But its late in the evening =).
> Even all that stuff, the "random" padding thing with stream ciphers is
> not too much work. It could be added to a TLS implementation in a couple
> of hours by any experienced TLS developer.
Doing that needs a revision of the RFC... would make sense either =).
Would it be possible to add a compression layer with different compression
levels?
Regards Rene
--
-----------------------------------------------------------
Rene G. Eberhard
Mail : [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
