[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #5488 [Analysis]: Write Internet drafts for one or two TLS features to improve its traffic-analysis resistance
#5488: Write Internet drafts for one or two TLS features to improve its traffic-
analysis resistance
----------------------+-----------------------------------------------------
Reporter: karsten | Owner: nickm
Type: project | Status: new
Priority: normal | Milestone: Sponsor F: November 1, 2012
Component: Analysis | Version:
Keywords: | Parent:
Points: | Actualpoints:
----------------------+-----------------------------------------------------
Comment(by asn):
It seems that Marsh not only wrote a draft for his idea, but the draft was
also quite well received by the TLS community:
https://www.ietf.org/mail-archive/web/tls/current/msg08722.html
He proposes two schemes:
One scheme, where the ClientHello is transferred in plaintext, the rest of
the discussion is encrypted, and the number of round trips is the same as
in classic TLS.
And another scheme, where a ''dummy'' ClientHello is initially
transferred, all the discussion is encrypted (including the ''actual''
ClientHello that carries extensions etc.), but the number of round trips
is increased by one.
If this proposal gets accepted and implemented, the browser/httpd vendors
will decide which of the two schemes to use, and this will decide which
scheme we will have to use.
In the last section, there is:
{{{
o It cannot be repeated often enough that the early encryption
negotiated by the EH extension *only* provides protection from
passive eavesdropper. It *can not* resist a man-in-the-middle
type active attacker who wishes to steal a sample of the plaintext
the client and server intended to exchange (doing so will break
the handshake however). Like TLS without EH, full protection from
an active attacker only begins after the Finished messages are
received and validated by each side.
}}}
since the proposal does not protect against MITM or active-probing-like
attacks.
I wonder if there is anything smart that can be done to add protection
against MITM.
For example, adding a post-Finished phase where parties could exchange
metadata would help against MITMs, but it would also add another round
trip. Furthermore, if such a phase was client-initiated and optional, we
would be able to use it only if everyone else did so too, otherwise we
would stand out against a passive adversary (lame plaintext TLS record
headers).
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5488#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs