May 07, 2005

Securing with SSL - an experiment

SSL is now used to protect the FC blog. It's an experiment. You will be bothered by a CACert, so I suggest you go to this URL: and install the CACert root certificate into your browser. Or go here for some help notes. The CACert guys are good guys, and their verification model is face to face rather than paper.

Also, you should turn off SSL v2 in your browser otherwise you will see instead of FC!. This is an older version of the protocol that breaks when trying to access multiple SSL sites over the same IP#. Sorry about that, the people who ship browsers should be turning it off for you as it would enable a lot more security. (Tell them!) If you end up on a different site after clicking around, that's what has happened. And if you find any site that still uses SSL v2, let us know and we'll send them into perdition.

The reason using SSL is novel and experimental rather than routine and boring is because SSL is not set up to protect browsing, but rather to protect ... well, that's not exactly clear - but it is strongly swayed to high value installations and complex installs. What that means is that if you have sysadmins on hand and programmers who know what they are doing then protecting with SSL can be done; for the rest of the world, expect a messy compromise, which is what you will see here, or no protection at all.

A good crypto protocol protects everything all the time - it's good because it doesn't expose the user to dodgy compromises or to expensive solutions that may break down due to their complexity. Simplicity is more than a virtue in protocol design, it's a necessity, and SSL shows little of it.

Ideally, all-the-time is what browsing should do, and when it doesn't, it should be easy to upgrade. People who disagree say that server load and time delay make protecting huge graphical downloads a fruitless exercise. I think this happens to be a particularly weak case, given the vast number of servers (around 1-10 million) sitting on the Internet doing nothing. Yes, more than 99% of them would be sitting at less than 1% activity. Right now, this server is hovering between 99.7% and 100.0% of idle. Give it some work I say!

I have layered the blog so that ordinary unprotected browsing is still a starting point (so http URLs will still work) but the site itself now uses https URLs everywhere. That's not intelligent on my part, that just seems to be the only way to do it such that it doesn't suck (this is my third or fourth method). So you will be sucked into SSL as you click around. Don't be afraid!

In terms of security, this means you won't be eavesdropped. Those critical comments will now not be so easy to track, and your browsing pleasure will remain private. It isn't much, I know, but there again, it's free and it should be the standard.

And, please feel free to grumble - this blog is for its readers. I'm not religiously devoted to SSL as you all know and if it fails to work, we'll discard it.

Posted by iang at May 7, 2005 03:45 PM | TrackBack

To turn off SSL in Firefox:
go to about:config, filter for SSL, doubleclick on the enable SSL2 option.

Also, why *

Posted by: name at May 7, 2005 04:22 PM

So I gather up all the information on the certificate presentation via a Mozilla Browser and I go to the CAcert site. Is it at any time availible to me to see if CAcert actually issued this certifcate or for that matter possible to review the procedures employed to determine if * is the same entity as the answer is no. While a machine generated Algorithm for signing maybe within the sphere of the Gods of crypto it is not readily availible to idiots like myself. So why doesn't CAcert have narrative descriptions of the certs they have signed on behalf of other like enhyper? Or for that matter explain what their process is for verification of the entity * I'm at a complete end to this rant other than simply stating SSL secure or not makes no difference since my reading habits are really boring anyway. It is also believed that the SSL certificate regime might be hackable.

Version 3
Serial Number 01:19:76
Certificate Signature Algorithm PKCS #1 MD5 With RSA Encryption
Issuer: E =
CN = CA Cert Signing Authority
OU =
O = Root CA
Validity Not Before 5/7/2005 14:29:21 PM
(5/7/2005 18:29:21 PM GMT)
Not After 11/3/2005 13:29:21 PM
(11/3/2005 18:29:21 PM GMT)

Subject CN = *

Subjects Public Key
30 81 89 02 81 81 00 d9 38 bf fe 9e be 87 ae d6
2f e9 53 db ec 14 6b 83 4b 21 72 e6 f6 a0 10 3b
a9 ad 8b df d6 17 88 5e 26 3c 51 c3 fc 9c dc 4c
ae 96 7c 6e a0 b2 58 08 e7 e7 ac 1b 43 d1 4b 03
8e 3a bd 03 23 03 5a db 17 ee 07 5a eb 7f de d3
91 5c d2 54 4a cc 01 b1 fd da 69 ca 6e d8 1a 2e
80 74 9b 73 f2 11 9c 61 ee 91 7c db 56 c0 69 25
c7 f2 20 4e a9 e4 c1 64 ad 58 86 6b f2 16 04 4b
cd 66 12 bd 4c 65 f3 02 03 01 00 01

Certificates Basic Constrainst
30 00

Extended Key Usage
Not Critical
30 2b 06 08 2b 06 01 05 05 07 03 02 06 08 2b 06
01 05 05 07 03 01 06 09 60 86 48 01 86 f8 42 04
01 06 0a 2b 06 01 04 01 82 37 0a 03 03

Certificates Key Usage
Not Critical
Key Encipherment

Crl Distribution Points
Not Critical
30 28 30 26 a0 24 a0 22 86 20 68 74 74 70 3a 2f
2f 77 77 77 2e 43 41 63 65 72 74 2e 6f 72 67 2f
72 65 76 6f 6b 65 2e 63 72 6c

Certificate Signature Algorithm
PKCS #1 MD5 With RSA Encryption

Certificates Signature Value
34 82 ea dd dc 54 46 9a b9 f9 05 65 14 d0 61 0e
5d 57 66 d3 67 ad 38 b5 20 6b e6 ca 4c 41 4b 58
9f b0 fa aa d7 60 fc 75 d2 ec ff c0 7e d3 71 0a
ae b7 83 fe a4 8e d8 6e 4d 1f fd 2d 7e 65 b8 fe
db b0 0f 9e 2d 73 44 2f eb f5 2f f8 3b 56 62 f8
d3 48 40 62 ed 25 66 73 3e eb d9 13 fe 73 a0 20
b6 49 5a 72 21 3c d9 51 72 4c 2e 7b 49 99 82 5a
70 bc dc af a1 66 f8 e7 f2 d2 67 01 e4 d3 44 65
d3 49 8b 07 8d 3b 43 4b bf 57 88 ae 22 84 7c 99
29 0c 10 a2 ab ab fb bb 2f fe 80 15 fd ae 1c 20
32 1c c5 a7 34 35 c0 f8 cf 61 97 49 ff 58 90 19
22 d9 e3 19 a4 08 97 ea c7 d6 73 33 93 5b bb 3b
85 7f fc 23 65 59 7c 02 c9 9a 7e 15 b9 bf 98 08
26 93 5a c7 52 5f 4e 10 aa eb a5 4c d7 49 75 83
70 77 c0 01 21 f2 19 7b 1f 59 2d b1 61 29 58 c1
8f 32 02 f4 a2 8d cf 22 89 0c 43 26 1d 39 99 90
2d 8c 5f 8e 21 1e 97 9b 54 23 1c f8 24 76 d3 53
49 90 e4 28 88 ca 11 4d 89 b8 de 89 26 b6 a1 46
29 3b 88 36 93 05 36 9c b5 ec 1b 36 ee 22 58 3f
aa d1 17 4e 07 6f 49 11 bb 65 2a dd f8 5b 9a ae
ef fb 72 e4 cf 7e 5d 2b a3 43 ee 72 c0 21 f1 c3
b7 bb de c0 ca db 9d e6 5c 0e 96 6f 70 c5 04 00
01 5b 4f b1 82 08 a4 93 52 6e 0b 95 2d 7a 7f 92
39 13 72 d3 17 82 d6 ea 3a 00 6c 43 59 cb 7f 60
d5 31 7d 31 4a 33 27 cb 3e aa 17 3b 87 29 94 e3
41 d8 f6 b2 f1 ea 4e 5d 31 1a e7 7e 6d 13 1c 30
f3 0a 7d 9a cf 1a 50 ef 2f 6b 8c 32 97 18 1b 80
4d 81 14 3e 84 25 c1 4a 79 22 0f 42 6c 1f 09 8e
74 f0 53 6a 2e 4e e9 26 ec 59 9f 85 49 f0 d2 85
88 3b 68 64 84 99 73 88 ca 4d bf 00 32 4e bd 3c
88 0b d4 c2 97 c2 62 74 a1 e8 bd 52 cf 9e 74 56
27 77 9b ed 7d 29 16 20 d0 3d f2 95 ec d1 d9 6d

Posted by: Jimbo at May 7, 2005 04:39 PM

Enhyper is currently set as the default site, it's one of the half dozen on that IP#.

Checking the cert is futile. What difference would it make if it said what you wanted it to say? We know so many ways to fiddle the system that any real attacker can win that game...

The benefit is stopping eavesdropping; which means that passwords and a sense of anonymity are now more secure. Before, passwords were entered in the clear. Ug.

Posted by: Anon at May 7, 2005 06:21 PM

I am glad to see that someone else thinks that SSL version 2 is obsolete - it should be retired, certainly as a default setting, in both browser and server software.

Network Solutions the company with the monopoly on .com and .net domain names, was ONLY accepting SSL ver 2 connections (no SSL v3 or TLS 1.0 allowed) from before last Christmas:

"Are your credit card details safe? Network Solutions .com domain name purchase or renewal only allowed via obsolete SSL version 2"

This lasted until just after the recent security incident involving the domain name hijack of the encrypted email company:

"Hushmail encrypted email provider domain compromised"

You also need to badger the authors of Blog XML or RSS Feed Aggregtor software e.g. Bloglines etc., as these do not support SSL connections at all.

On the positive side, you will get rather less comment and trackback spam on an SSL only blog (for now), and that which you do get will tend to reveal more real IP addresses normally hidden by the open proxy servers which spammers abuse (until they get the hang of SSL proxies)

Posted by: Watching Them, Watching Us at May 7, 2005 07:08 PM

Who is this man in the middle? Is he like the Man in the Mirror? Or perhaps no man is an island. The attack from someone dropping into steal credit information or any information has been more one of human engineering. So alas the solution derived was one dedicated to a technical community not a stupid (like myself) narrative world one where pictures explain things and we strive to color inside the lines. What does this spell? Well I would say that defense of SSL when not combined with a strong human engineering feature is something my horse would object to. While it is true all cats look alike in the dark answers for issues confronting us now (the real people using the stuff made by the technoratti) are few we are told its OK just buy some more snake oil. The issue is we have had money stolen, acounts locked up, and many more things happen along the lines of identity theft all prompting the response SSL is secure. SSL my( vague reference to another farm animal)***. If the issue of man in the middle was such a concern then why didn't the issue of key loggers and phony phishing sites get addressed in the design features of browsers? The answer is people that design systems and applications do not like those that do not read in a digital fashion. The arrogance of you Jedi out there has created an imbalance in the force and will be corrected when the purge of the technoratti happens. This of course has historical merit since the industrial revolution in England was filled with workers destroying machines for fear their jobs would be stolen. A good question to ask your self goes like this Self if I where a normal human being what would I want? of Self if I wanted to design something for a village idiot to use how would I create it? Of course I place myself as the village idiot thats why I'm saying anything. So if my mate George has his account info stolen and his portfolio is being sold and the bank wiring instructions changed to one where he does not own the account what shall I say. I say fix it don't tell me SSL was in place find what was wrong. Village idiots like myself tend to have bad manners and even worst coping skills. At the present time I spend more time cleaing my email account of spam that reading the mail. I will probably have my credit information stolen at some level. As Rome burns the fiddles can be heard playing the SSL funeral march. Do we have to wait for every pensioners account to be robbed before corporate IT folks say du I thought SSL covered all the issues. Maybe just maybe if I get robbed enough some rich CIO will decide this stuff is wrong someone must fix it lets have a meeting maybe two, hire some consultant rewrite his report, and finally consult legal for escape clauses because when people get robbed they tend to get angry. Microkernels, Capabilities based systems, honest data brokers, governance scenarios described in detail, and finally no more pump up the SSL stuff it serves no purpose. The village people could hire their own trusted parties and allow them to field the questions of the day.

Posted by: Jimbo at May 8, 2005 07:41 AM

So it seems that the SSL experiment has not been brilliantly successful. It seems as though the Apache 2 webserver does not want to handle multiple certs over the different https domains. More research required ... in the meantime if anyone knows how to set up Apache to do that then let me know.

I went to and they now seem to be using SSLv3/TLSv1. Any other sites that we need to name and shame? We really need to be able to share SSL over single IP#s... otherwise it is simply too expensive to use.

Posted by: Iang at May 8, 2005 01:02 PM

When reading Jimbo's posting, I kept substituting terms like "WiFi" or "Bluetooth" or "Microsoft" or "*nix" etc. for "SSL", and it still made sense.

Using SSL for me is all about Motive, Means, Opportunity risk reduction. The people who are most likely to be snooping on my privacy with the means to do so are my local network systems adminstrators at work, at my ISP or cyber cafe etc. rather than well funded highly technical attackers like government agencies. The fact that SSL is built into most web browser software, for free, by default is the most significant feature of it by far, but nobody has ever pretended that it magically secures the the world wide web or email etc. on its own, any more than the 5 lever Chubb lock on my front door secures my windows against burglars.

Regarding Nerwork Solutions, yes they do seem to have fixed their server misconfiguration after the Hushmail incident, unless the problem is still lurking intermittently as part of a load balanced cluster. If I were responsible for any important .com or .net e-commerce website using Network Solutions as the domain name registrar directly, I would change my Network Solutions customer administration DNS management passwords now, just in case they were vulnerable to a possible SSL v2 cipher strength downgrade attack.

Posted by: Watching Them, Watching Us at May 9, 2005 10:35 AM

Interesting, I didn't know SSL v3 was capable of handling multiple domains over the same IP.

I came up with a rather ugly solution for this problem:
Redirects to
which runs on a different port than
but the same IP.

I was somewhat surprised that by entering a http URL for FC, I was presented a certificate, without being redirected to a https URL. I'm still not sure what has happened there. Looks like I will have to spend some time reading up on SSL v3.

Speaking of SSL: is there a way to prove to a third party that I have downloaded a certain page from a certain source?

Posted by: Daniel A. Nagy at May 9, 2005 11:06 PM
Post a comment

Remember personal info?

Hit preview to see your comment as it would be displayed.