[Ach] were you aware of this?

Aaron Zauner azet at azet.org
Sun Nov 3 20:27:30 CET 2013

On 03 Nov 2013, at 19:43, Thomas Schreck <tom at schreck-thomas.de> wrote:

> Hi *,
> Aaron just told me about your idea and really like it. I have
> currently a lot of discussions within Siemens about that topic, even
> we have a good working PKI infrastructure.
> I currently have two questions to the group:
> (1) What is your option on RC4 vs. AES?


See http://www.isg.rhul.ac.uk/tls/ for more information on current research regarding RC4 insecurity.

Many security bloggers and companies previously told admins to switch from AES-CBC to RC4 to prevent exploitation of the BEAST vulnerability, although most browser vendors patched this issue soon after BEAST was made public. So there are currently still a lot of websites relying on RC4 for encryption which is a problem in my opinion. The RC4 vulnerability is - to the best of my knowledge - currently only effective in lab. setups, but as with many other SSL/TLS vulnerabilities it’s just a matter of time until PoCs hit the wire. Think CRIME and padding-oracle attacks for example, these have been studied in theory a long time ago and have been presented as applicable to real-world scenarios only a few years later (that is - publicly, nobody knows if these vulnerabilities has been exploited privately before). RC4 vs AES-CBC is still a widely discussed topic in the security community and on internet platforms. The best option would be to use AES-GCM but most browsers still do not support counter mode (the chrome[ium] team is actively working on that, as far as i know).

> (2) How do you deal with TLS 1.2?

For now a lot of clients do not support TLS 1.2 (properly) - so we’re left TLS 1.0, 1.1,.. this will hopefully change pretty soon, since a lot of browsers do support TLS 1.2 already. but users and enterprise admins need to employ a proper update strategy. I try to support TLS 1.2 where possible (which actually is a pain with RHEL and its community forks,..).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1091 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.cert.at/pipermail/ach/attachments/20131103/73481577/attachment.sig>

More information about the Ach mailing list