|
Posted by Anonymous on October 28, 2007, 6:52 am
If you were Registered and logged in, you could reply and use other advanced thread options
>
> >So, I ask ... how can I tell if a certificate is impersonated by a rogue
> >Tor? I routinely say yes to all certificate requests because I never
> >understood them. Now I will take the time to read them.
>
> Good plan. In general, any error at all in a SSL certificate and you
> should be suspicious.
>
> You can pull the fingerprint and compare it against the fingerprint of
> that same SSL certificate provided via another method (like from a
> different internet connection, and not passing through Tor), and then
> once you've confirmed the error, safely proceed, but otherwise, by
> ignoring SSL errors you are all but not using SSL at all.
Agreed. The whole problem boils down to users not paying attention to
the warnings in front of their faces, or not using secure methods at
all.
> (Well, in practice you're raising the bar to snoop on your traffic from
> just sniffing to man-in-the-middle attacks. Tor is ideal for
MITM attacks have been occurring since long before Tor was ever in use.
Packages like dsniff have been around since the late 90's, including
specifc tools to spoof DNS, and then attack both SSH and SSL/HTTPS
connections. They're part of the reason SSH and SSL have evolved much
of their authenticity checking. My SSH client for example, absolutely
refuses to connect if keys change until the old key is manually removed
and the new one accepted.
Tor makes it a little easier for certain levels of technically inept
attackers to attempt certain attacks, but it in no way changes the
nature of the attack itself. The protocols and specifications will
protect you just the same over a Tor connection as they will a naked
connection.
> man-in-the-middle attacks since you're intentionally passing your
> traffic through several more hosts)
>
> >But, what does a fake SSL situation look like?
> >
> >For example, I just initiated a connection to my legimate router:
> > https://192.168.1.1
> >And it said (as it always does):
> > "Security Error: Domain Name Mismatch"
> >It went on:
> > "You have attempted to establish a connection with 192.168.1.1.
> > However, the security certificate presented belongs to Linksys.
> > It is possible, though unlikely, that someone may be trying to
> > intercept your communications with this web site.
> >It gave the recommendation:
> > "If you suspect the certificate shown does not belong to
> > 192.168.1.1, please cancel the connection and notify the
> > site administrator?
>
> The example above is a perfect case of a forgery -- Your router has an
> invalid certificate, and the SSL layer is offering virtually no
> protection against anything other then casual snooping.
???
The SSL certificate used by your router *must* be registered to the
router manufacturer, not some arbitrary IP address. This is a perfect
case of a valid certificate generating the warnings it's suppose to
generate because it's used in an implementation where it's impossible
to do it any other way and still maintain a secure connection to your
router. Linksys has no way of knowing that what your router's internal
IP address will be.
> A more common forgery case would be a valid URL, valid not-expired
> timestamp, but a certificate which was not signed by a trusted authority
> (And is otherwise 100% valid and complete)
Which also generates warnings and/or errors, and can't be installed or
even accepted by some software.
These types of forgeries are very uncommon though, because they require
that the attacker generate and selectively substitute unsigned
certificates for a whole range of potential targets. And do it in the
hopes that they're going to be the first one to submit the bogus
certificate to a potential victim, who in turn ignores the "unsigned"
warnings.
The chances of success are next to zero. It's a fruitless waste of
resources to generate certs with "Forged" UID's. Just as easy to
generate one, possibly even get it officially certified, and then
substitute that for the targets real certificate in hopes that a user
will miss the "changed" and/or "doesn't match" error.
SSL has been around for quite a while now. It's paid its dues. The
attacks we're talking about here are nowhere as easy to launch as some
people apparently think they are. Under normal circumstances (Tor usage
included) they're impossible to launch. It's only very rare cases of
user negligence or broken software where they'll have any chance at
success.
| 
XML site map