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
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
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.
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?
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.
(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.