2006-11-19
How https: should work
I just got yet another prompt about certificate issues on the occasion of visiting yet another website (I think because it had a self-signed certificate, but who can tell with Firefox's dialog about it?). And all this reminded me of how badly implemented SSL is in web browsers.
There are three actual good things that can be done with SSL: encrypting the conversation, stopping man in the middle attacks, and certifying that the website is in some sense trustworthy. The web SSL experience is so bad because right from the start, browsers tried to roll this all into one blob that's strongly biased towards the last thing.
Here's how it should work:
- always use the website's SSL certificate to encrypt the connection.
Whatever else is going on, you're no worse off than if you were not
using SSL.
- only turn the address bar yellow, lock the little padlock, and so
on if the certificate is fully signed and valid. (In fact, make a
slightly bigger deal of it than browsers do today, to make it
clearer to users.)
- to guard against man in the middle attacks, insist that the
certificate either be the same certificate that you saw the last
time you visited or that it be fully signed and valid. Be especially
insistent about this if you saw a fully signed and valid certificate
last time.
You can't insist that it always be the same certificate; certificates expire, and people can start out with self-signed certificates and later upgrade to 'official' ones. (For similar reasons, you can't insist that the new cert be signed by the same root organization as the old one.)
I think that this would actually provide better protection against man in the middle attacks than the current approach does. The problem today is that by making SSL certificate warnings relatively routine the current approach teaches users to just click OK and go on, while at the same time failing to detect or draw attention to the genuinely dangerous cases.
These changes are unlikely to happen, because the browser SSL world is by and large in the twin grasps of the people who demand mathematically perfect security and the people who make a great deal of money from getting websites to buy signed SSL certificates. The latter have no interest in making non-signed SSL certificates more useful, and the former can point out all of the ways that this approach could fail (never mind that it would probably vastly increase the amount of encrypted HTTP in actual use).
(Yes, yes, by now it's too late; no one is going to switch from http: to https: with self-signed certificates until a large majority of the browsers in the field no longer give (scary) warnings about it, which means that if Firefox, IE, Safari, and Opera all made the change right now we might see significant sites thinking about it in, oh, 2008. I can still dream, and besides, I run bleeding edge CVS snapshot versions of Firefox, so I'd win right away.)
Weekly spam summary on November 18th, 2006
This week, we:
- got 15,266 messages from 269 different IP addresses.
- handled 22,009 sessions from 1,693 different IP addresses.
- received 897,934 connections from at least 48,417 different IP addresses.
- hit a highwater of 10 connections being checked at once.
Just like last time, that is not a typo (and nothing on the system was affected enough to make me notice it before now, when my scripts started spitting out information for this). Apart from the huge connection volume, things are pretty much the same as last week; ironically, the highwater is lower.
Day | Connections | different IPs |
Sunday | 27,857 | +7,529 |
Monday | 25,752 | +6,652 |
Tuesday | 32,064 | +7,395 |
Wednesday | 32,050 | +7,526 |
Thursday | 173,814 | +7,585 |
Friday | 312,437 | +6,042 |
Saturday | 293,960 | +5,688 |
Kernel level packet filtering top ten:
Host/Mask Packets Bytes 64.166.14.222 12859 617K 213.4.149.66 7756 403K 212.216.176.0/24 6340 312K 213.4.149.12 6325 329K 61.128.0.0/10 5730 314K 216.102.133.220 5532 259K 64.216.74.90 4732 227K 67.153.140.35 4396 224K 203.113.158.222 4261 205K 210.50.231.134 3947 181K
Overall things are quieter than last week.
- 64.166.14.222 and 213.4.149.12 return from last week.
- 213.4.149.66 and 210.50.231.134 got blocked for repeated bad
HELO
s. - 216.102.133.220 is listed in
dul.dnsbl.sorbs.net
, although its hostname and WHOIS information doesn't look like a dynamic IP address. My best theory is that SORBS just listed the large SBC Internet block that it's in. - 64.216.74.90 was blocked for repeatedly trying to send us phish spam.
- 67.153.140.35 is an algx.net dynamic IP address.
- 203.113.158.222 is a Vietnamese IP address with no reverse DNS.
Connection time rejection stats:
46168 total 26202 dynamic IP 15926 bad or no reverse DNS 2374 class bl-cbl 317 class bl-sdul 285 class bl-dsbl 206 class bl-njabl 89 class bl-spews 76 cuttingedgemedia.com 40 class bl-sbl 38 class bl-ordb
Good old Cutting Edge Media; apparently they never give up. But then, this is completely typical of spammers. That these numbers are not hugely larger than last week suggests that most of the connections were greylisted away.
Three of the top 30 most rejected IP addresses were rejected 100
times or more; the leader was an internal UofT machine, followed by
80.24.154.168 (135 times) and 64.166.14.222 (134 times). 16 of the top
30 are currently in the CBL and 4 are currently in bl.spamcop.net
.
This week's Hotmail numbers:
- 3 messages accepted, at least one of which was spam (I know because I got it).
- 1 message rejected because it came from a non-Hotmail email address (in this case, a msn.com username).
- 41 messages sent to our spamtraps.
- 5 messages refused because their sender addresses had already hit our spamtraps.
- no messages refused due to their origin IP address.
And the final numbers:
what | # this week | (distinct IPs) | # last week | (distinct IPs) |
Bad HELO s |
2008 | 175 | 1780 | 151 |
Bad bounces | 470 | 374 | 482 | 416 |
This week's winning bounce target is tosi
, with 11 hits, then a couple
of old usernames. Plausible usernames (as opposed to the usual random
jumbles) seem to be the popular thing this week.
(Next week's bad bounces numbers are probably going to jump some, because I changed how we track them a bit. Up until now, we've only been logging the first bad bounce in a given SMTP session, for reasons that don't fit in this margin; we're now logging all of them.)