Re: [tor-talk] Email provider for privacy-minded folk

[survivd <survivd@xxxxxxxxx>]

[set
> where, & how is it stored, for how long?]

Specific location will depend on the browser and implementation.  There
may be guidance in the RFC but I can't remember the specifics.  You
could check https://tools.ietf.org/html/rfc6797 and the chrome/firefox
implementations to get the exact details.

*"because you must catch the very first connection on an _empty browser
> store_."*

This is referring to the blackhat's perspective.  If you want to do a
cert replacement mitm attack against a client for an hsts site, you'd
have to perform it ("catch" the victim's request) the very first time
they ever visit that hsts site (because otherwise a long-lived
authentication token is set in the browser's data store that says "hey,
this is the specific ssl certificate this site should have, and if it
doesn't match this, it's bullshit").  Basically, if you try to swap the
cert and the browser knows that's not the right cert, it should
hard-fail (not just give you a "hey, are you sure this is the right
cert?" dummy box) because it knows there are shenanigans afoot.


*as an inherent consequence of his fresh root* blah blah

This is explaining that since you can't easily downgrade https
(encrypted) connections to http (unencrypted) for HSTS sites as a "bad
exit" by modifying the connection requests themselves (which is how ssl
stripping works), you would use a different vector.  It's a little less
convenient, but still pretty easy for a reasonably sophisticated actor.
 Basically, instead of trying to mess with the https connections, you
poison the content of any requested http pages proxied through your exit
node with browser exploits (you can drop in any you choose on the fly)
targeting the fingerprint of that particular browser (or just
shotgunning it if you don't care about being noisy, but that's lazy).
Since the idea of a browser exploit is to execute arbitrary code (i.e.
whatever the attacker wants), the bad guy can basically give himself
persistent root (administrator) access to the victim's machine.  This is
obviously a way more reliable approach than the blackhat simply crossing
his fingers and hoping he catches somebody's first access to an HSTS
site.  Once he has root, he gets the plaintext of the victim's https
connections (since he owns your machine... he can see your tx/rx data
before you've encrypted it to the server and after you've decrypted it
from the server).

As a fringe benefit, this now works for him regardless of whether or not
you're connected to Tor, because he owns your machine basically until
you reformat.

Make sense?





On 2/21/2013 3:44 PM, Joe Btfsplk wrote:
> On 2/21/2013 4:58 PM, survivd wrote:
>> Seems like there's a bit of confusion regarding what a bad exit node can
>> and can't do here.
>>
>> For many sites, you can trivially strip the SSL connection request as
>> the exit node, downgrading it to vulnerable plaintext just by using
>> ssl-strip.  There'd be no cert warning, but smart users will notice the
>> connection is http instead of https.
>>
>> Gmail is not one of those sites.  Gmail forces HSTS, so he couldn't
>> ignore the certificate warning even if he wanted to because the HSTS req
>> is pinned in the browser itself (with any reasonably modern browser) and
>> if you've EVER securely visited gmail, an HSTS token indicating the
>> proper cert for the site is set that should prevent MITM "replacement
>> cert" attacks.  Bottom line: an exit node simply can't SSL-strip an HSTS
>> site, and MITM is practically impossible, because you must catch the
>> very first connection on an empty browser store.
>>
>> That said, it's still basically effortless for an exit node to exploit
>> it clients by injecting fingerprint-based iframe-style attacks into
>> whatever lowsec http pages you've requested, which gives abu al-badguy,
>> as an inherent consequence of his fresh root, access to the plaintext of
>> your https connections.  Basically, trojaning your box and snagging your
>> un/pw fields clientside is much more reliable for HSTS sites.
>>
>> Torproject doesn't currently do very much to detect this kind of attack
>> (imo they should at least have an agent automatically comparing
>> known-good site requests with what they actually receive from each exit
>> and flagging unusual variations), and the "bad exit" vector is unlikely
>> to go away soon.  In fairness, there are only so many devs, and most of
>> them pooh-pooh realistic (paranoid) threat models.
>>
> I know what most of the words mean.  I understand much of the context. 
> Some things I don't understand:
> In more simple terms, what do
> *"an HSTS token indicating the proper cert for the site is set"*... 
> and
>  *"because you must catch the very first connection on an _empty browser
> store_."* mean?
> 
> This paragraph is confusing, in relation to its preceding paragraph:
> "That said, it's still basically effortless for an exit node to exploit
> it clients by injecting fingerprint-based iframe-style attacks into
> whatever lowsec http pages you've requested, which gives abu al-badguy,
> *as an inherent consequence of his fresh root*, access to the *plaintext
> of your https* connections. Basically, trojaning your box and snagging
> your un/pw fields clientside *is much more reliable _for HSTS_ sites*."
> 
> Can you explain the last paragraph / statements?
> Thanks.
> _______________________________________________
> tor-talk mailing list
> tor-talk@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
> 

_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk