Open Wi-Fi Hotspots [telecom]

I have a wireless router from Fon

) that allows allocation of a portion of the total bandwidth for use by others. It is free to other Fon members and a few bucks a day for non- members. I think it's a clever idea. I've had it for several years now. So far I've had a few paid users, but no other Fom members use the router.

On encryption, as discussed in the article, use of HTTPS seems like it handles it. I use Squirrel Mail as my web mail system and HTTPS to access it.

Harold

***** Moderator's Note *****

One of the certificate authorities recently discovered that it had mistakenly issued certs for websites that weren't owned by the domain name registrant. No system is perfect: SSL has weak points, too.

Bill Horne Moderator

I thought fake certs allowed someone to pretend to be someone else but not decrypt SSL communications with another site. The fake cert would allow someone to set up a fake bank website, which would be good for phishing, but would it allow decryption of my conversation with the real bank website?

Thanks!

Harold

You are theoretically correct. However, if a user is lured to a fake website whose owner has managed to obtain a "valid" SSL certificate for the domain name the user expects, then the user might be fooled when his browser shows a padlock icon.

Although a third party won't be able to eavesdrop on your communication with your bank, they _also_ won't be able to eavesdrop on your communication with a fake site that has obtained a "valid" SSL certificate. In the case I was writing about, the encryption is still OK, but the implementation has been compromised.

Most browsers will warn users of a domain name/ip address mismatch

*IF* the option is enabled, but that's not the case for older browsers or some corporate environments or users who chose to disable safety features. It's also a moot point if an attacker has managed to compromise the HOSTS table on a victim's computer, which is still used by every TCP/IP implementation I know of, since (in that case) the IP address *IS* "correct" for that domain. Of course, if an attacker has been able to change the HOSTS table, the odds are that (s)he has _also_ been able to insert a "Root" certificate into the browser's trusted certificate cache, thus allowing him/her to point the machine at a completely fake site which uses a self-generated SSL certificate.

It's a subtle difference, to be sure, but it's a truism that PKI (Public Key Infrastructure) cryptography is 10% process and 90% procedure. If Certificate Authorities don't follow proper procedure, or users don't secure their machines, then the system breaks at a fundamental level that current implementations can't prevent.

Bill

-- (Filter QRM for direct replies)

SSL has two different purposes: (1) ensuring that you are communicating with (and giving your credit card number to) the thief you think you are talking with, and

(2) ensuring that all the other thieves can't listen in and get a crack at your credit card before the first thief puts it unencrypted on a laptop and loses it at an airport.

If you only need (2), an anonymous self-signed certificate with no owner name/identification on it whatsoever for each web server is sufficient. You don't need certificate authorities at all. Most of the user-visible features of SSL in a browser are for (1).

If the site uses a man-in-the-middle attack, that is, setting up its own connection to the real banking site and passing info from one connection to another, it can decrypt both sides of the conversation (and log passwords, etc.) because it is on one end of each SSL connection. To the user, it may appear that the site is the real one, including giving up-to-date balances and transactions, and transactions entered get executed (and perhaps some transactions are initiated at the fake site's initiative).

Also, if you have a complete transcript of an SSL conversation, and you have the private key of the server certificate, you can decrypt the conversation. You can also do it in real time if you've got the software set up to do this. It is probably much easier for the fake site owner to have the server log the conversation than try to wiretap the connection.

Yes, if you fall victim to a man-in-the-middle attack (one reason why DNS spoofing is worth attempting) and contact the fake site thinking it's real, and it contacts the real site and acts as a proxy between you. No otherwise.

......... I set up Windows SBS servers on an ongoing basis and one of their features is remote web access to e-mail etc., and Self-issued certificates work well (I also have a philosophical objection to paying a third-party outrageous annual fees to "certify" to others that I am who I am).

Most users don't know or care what colour the funny little padlock icon on their browser is.

Yes. And optionally but rarely (3) ensuring you are the thief the other thief thinks *he* is talking with (aka client-authentication).

Or there are DH_anon aka ADH ciphersuites which use no certificate at all (as opposed to a meaningless one), but these usually are disabled by default and thus require functioning brain cells to use.

Only for kRSA, or static [EC]DH which I have never seen anyone use. Ephemeral [EC]DH (using adequate entropy) provides 'forward secrecy': (later) compromise of the private key allows impersonation (with the legit cert, undetectable unless the cert is revoked and the relier checks) but does not expose past (or even future independent) sessions. k[EC]DHE can be used with aRSA or a[EC]DSA authentication, or as above no authentication.