On 14/02/2015 16:55 pm, Tero Kivinen wrote:
Stephen Farrell writes:
Tero,
On 13/02/15 13:04, Tero Kivinen wrote:
If you want to protect against active attack you need policy which
will authenticate the other end and which do not allow any
unauthenticated unencrypted connections between peer.
I don't believe that is entirely true.
With an s/protect against/prevent/ it would be true.
Prevention is not the only form of protection.
I do not think preventing is correct either, as we do not really
prevent or protect against, we can simply detect the active attacks,
and stop communications....
Right, it's hard to see how one can 'prevent' an active attack as both
sides presumably have the option to stop communications entirely, and
that is only a loss for us.
Terminology matters, if only to help against silly arguments. In the
risk world, we talk about 'mitigating' an attack rather than preventing
it. In this sense, we mitigate active attacks by logging.
That's a sort of recognition in risk world that no attack can actually
be stopped entirely, and economics matters. Something that is more true
in the physical world than say the cryptographic world.
If one has protection against a passive attack and if that is used
in almost all cases then that makes the cases where it is not used
interesting, and possibly things to investigate.
When most of the people will safely ignore the broken lock and big
warnings which come up when the authentication of the connection fails
on methods which do require authentication like TLS, how do you expect
anybody to really bother whether invisible behind the scenes method
like tcpinc would suddenly sometimes fall back to clear text...
Right. This is really not about protecting or mitigating from 99.9% to
99.95%. It's about leaving enough of a trail such that anyone who does
do the obvious RFC-advised tricks will eventually be outed.
We saw exactly that pattern happen with an ISP that was causing
SMTP/STARTTLS to fall back to cleartext recently.
Or the dropping to the cleartext when using postfix + openssl 1.0.1g
and talking to the unpatched ironport. At least sendmail users did get
complains that mails do not work anymore as it considered handshake
failure as temporary error and did not fall back to cleartext if other
end claimed to support TLS. I think most of the postfix users never
even noticed that issue. At least several places in Finland are still
using unpatched ironports...
This is working well. I've noticed that every second free wifi in some
public space is MITMing and consequently it all breaks down.
So passive protection is also some level of protection against
active attacks that are easily spotted, such as those that cause
a fallback to cleartext.
Regardless whether we protect FIN or RST, the fact that two peers did
talk with tcpinc and then next connection got dropped to cleartext, or
got its key changed, should cause some kind of audit event. Whether
anybody is ever noticing that audit event does not really matter.
+1
iang
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
