Wandering Thoughts archives


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.)

web/HowHttpsShouldWork written at 13:16:22; Add Comment

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         12859    617K           7756    403K       6340    312K           6325    329K          5730    314K        5532    259K           4732    227K          4396    224K        4261    205K         3947    181K

Overall things are quieter than last week.

  • and return from last week.
  • and got blocked for repeated bad HELOs.
  • 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.
  • was blocked for repeatedly trying to send us phish spam.
  • is an algx.net dynamic IP address.
  • 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 (135 times) and (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 HELOs 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.)

spam/SpamSummary-2006-11-18 written at 02:36:51; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.