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.