[Ach] filippo on SSL SMTP encryption

[Aaron Zauner]

Hi,

Manuel Kraus wrote:
> Since many adversaries sit on carrier links, the MITM-attack will be one
> of the most important ones. Playing with forged certificates (to gain
> access to a HTTP header exchange) or simply poisoning cleartext
> connections, both having DoS in mind, will be quite neat stuff for those.

I don't think you get the full picture here. Such an adversary has a
/very/ high interest in his work being undetected. If they would be to
massively DoS popular websites with injecting fake headers that would be
noticed immediately. They also can't use these attacks to gain information.

So, yes: if you're on a carrier/backbone link and able to inject data in
time, have access to a CA - you're able to DoS HPKP and -- maybe -- able
to switch out HPKP headers on the first time of use. This effectively
results in a DoS attack that will be detected almost immediately with no
real advantage for the attacker, or am I missing something?

Providers like Google and the likes monitor what their clients see very
closely to detect such attacks in time. This is also how they have been
able to find numerous attacks (intentional or unintentional) via CAs
over the last couple of years. Certificate Transparency democratizes
this even more.

> It's better to have failed connections only from time to time (as result
> of adversary's DNSSEC manipulation trials) instead of going dark for
> ages because the own webbrowser says so.

Did nobody read my "DNSSEC doesn't work" post? :)

No really. DNSSEC gives you /nothing/ over that, because neither your
browser nor your local Operating System will be able to tell you that
something is fishy and the chance of something soft-failing in the
DNSSEC stack is not likely but almost certain.

Aaron


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20150401/2bfa1ba9/attachment.sig>