[13807] in cryptography@c2.net mail archive
Re: replay & integrity
daemon@ATHENA.MIT.EDU (Anton Stiglic)
Wed Jul 9 14:02:22 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
From: "Anton Stiglic" <astiglic@okiok.com>
To: <cryptography@metzdowd.com>
Date: Wed, 9 Jul 2003 13:57:36 -0400
> Integrity: Financial protocols that use crypto
> (as opposed to ones abused by crypto) generally
> include signed messages. The signature provides
> for its own integrity, as well as a few other
> things.
I don't believe that is enough. Take for example
the SSL 2.0 ciphersuite rollback vulnerability or the
SSL 3.0 key-exchange algorithm vulnerability . Any kind
of rollback attack is serious, and won't be protected
by signatures in the bulk data (and those signature might
be weakened by forcing a rollback to a possible weaker
version/implementation).
>
> Replay: One of the commonest problems in HTTPS
> sites is replay failure. The solution is well
> known out in the real world - you have to have
> replay prevention at the higher layers.
>
> (Credit card processors have replay prevention
> too!)
>
> So, some protocols don't need replay prevention
> from lower layers because they have sufficient
> checks built in. This would apply to any protocols
> that have financial significance; in general, no
> protocol should be without its own unique Ids.
So maybe I can't replay a complete financial transaction,
because at some high layer there is replay prevention,
what about replaying some init protocol request?
Is that not annoying? Would a bank not care that
their ATMs are not working for a day because someone
is executing a DoS attack on the lower layers of the
protocols of their system? I think not, you need replay
protection on both levels.
How can a secure socket be dubbed secure if it doesn't
protect against these basic attacks?
To quote from Wagner and Schneier`s paper, Analysis
of the SSL 3.0 protocol:
"Replay attacks are a legitimate concern, and as they are
so easy to protect against, it would be irresponsible to fail
to address these threats."
--Anton
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
