Quote from: OneOfMany on July 31, 2011, 06:57 amSomeone here suggested safe-mail.net, which seems to work fine. It does have one very Tor-unfriendly security feature of forcing you to re-enter your password whenever your IP address changes, but this can be disabled.Godammit.DO NOT fuck around with features you do not understand, and DO NOT disable the re-verify password on IP change feature on safe-mail.net, or any other site you access over TOR. That is a TOR-friendly feature, in fact designed so the site can *safely* be used when your IP address changes often.Safe-mail is attempting to ensure that it continues to be YOU, and not someone pretending to be you using a Man-In-The-Middle (MITM) attack to impersonate you and hijack your session, thereby gaining unrestricted access to your email account. As early as 4 years ago Mike Perry reported at the Black Hat 2007 Conference (hxxp://www.blackhat.com/presentations/bh-usa-07/Perry/Whitepaper/bh-usa-07-perry-WP.pdf) that during TOR Centralized Bandwidth and Load Scanning tests that replay attacks by Chinese ISP's running nodes was very common. I'm sure since then everyone from the DEA to the NSA down to the local script kiddie on your block has got into the action.Safe-mail, or any other site for that matter, uses several metrics to ensure that you are still you durring a session. First off, it uses a unique session fingerprint when you first connect, which includes information from your connecting IP address. This is enough for the server, but might not be available or sufficient for the SAS app you are connecting to. To allow for changing IP's, the SAS further relies on either cookies, whether written to disk or ethereal session cookies, and possibly a unique session id.Forcing an SAS app to rely on the session id alone is where you are inviting trouble. A malicious node intercepts your traffic, and replays it, pretending it came from them. They can be impersonating either you or the site at this point in time - they don't know which is which, and it doesn't matter to them. What they're waiting for is a successful response. If they replay a session of yours with a valid session id, but from a different IP address, the only way they are going to get in is if you have disabled the SAS apps IP address checking feature.Also note that it doesn't matter that TOR has encrypted the packet(s) they're relaying. The attacker isn't trying to read your packets, it's trying to use them as a key. If all that takes is replaying an encrypted session id, they then simply act like they got a 304 in repsonse, and the SAS app host then merrily renegotiates a NEW encrypted session, which is now that attacker playing merrily about in your mailbox.Keep in mind, all this is automated on their end, and a malicious node can sift through billions of packets until it sees potential session header response packets, and then try to hijack millions of those.All day.Every day.Finally, this shit isn't just 'theoretical' like the bullshit about you having to wipe your drive 35 times with different random data to safely delete it. (You don't, btw.) TOR by design changes your exit relay every 10 minutes under most circumstances, and gives you a new relay node each session. (Generally speaking, you only ever use 2 Guard nodes, which never change.) This gives malicious nodes lots of opportunities to sift through new traffic.A peek at my TOR logs for the last 24 hours shows the following attempts by unknown third parties to initiate MITM / replay attacks:QuoteJul 30 19:32:34.396 [Warning] Possible replay detected! We received an INTRODUCE2 cell with same first part of Diffie-Hellman handshake 2 seconds ago. Dropping cell.Jul 30 20:35:02.484 [Warning] Possible replay detected! We received an INTRODUCE2 cell with same first part of Diffie-Hellman handshake 1 seconds ago. Dropping cell.Jul 30 22:08:59.083 [Warning] Possible replay detected! We received an INTRODUCE2 cell with same first part of Diffie-Hellman handshake 5 seconds ago. Dropping cell.Jul 30 23:54:37.419 [Warning] Possible replay detected! We received an INTRODUCE2 cell with same first part of Diffie-Hellman handshake 3 seconds ago. Dropping cell.Jul 31 00:35:33.476 [Warning] Possible replay detected! We received an INTRODUCE2 cell with same first part of Diffie-Hellman handshake 2 seconds ago. Dropping cell.Jul 31 10:15:39.498 [Warning] Possible replay detected! We received an INTRODUCE2 cell with same first part of Diffie-Hellman handshake 1 seconds ago. Dropping cell.Note that these attempts at replay attacks are common, and aren't directed at anyone in particular, but rather are a wide net cast by malicious exit and relay nodes, and even possibly a 'trusted' guard node.So when your IP address changes, and safe-mail asks you to verify you are really you before proceeding, smile, and thank the folks who put that feature in there to protect you.