Financial Cryptography

to the sites authors defense. The topics brought up on this blog have covered topics of interest to me and I like the information. So its not for everone.

Posted by: Jim Nesfield at November 18, 2006 08:11 PM

CA (certificate authority) certificates help the illusion of security for the retail user of a Web site. Get into the nuts and bolts of the certification that a CA does and you will realize that it is all be bit iffy.

On top of that there are other security issues that the code in the browsers, in the past and as of now, will not address.
Most are not aware of this. Financial Cryptography has gotten into this in the past so you would have to spend time going over the past posts to get the big picture or to see how to start to think about the whole browser security scene.

I wouldn't take Financial Cryptography's cert seriously particulary since there is no financial transactions taking place. Ask yourself why FC even has a cert. Is FC trying to make point?

Way back I got myself an open source CA to use on a site that I don't have anymore. It went bust. Would I use it again on a new site that envolved financial transactions? Yes, but more to give an impression of security than to help providing real security.

Hang in there and study past posts.

Posted by: bob at November 18, 2006 09:43 PM

I did offer to help you with this in the past :P

Posted by: Duane at November 19, 2006 07:40 AM

To the Grnch: It's _Financial_ Cryptography, which is about using crypto ... amongst many other things. We do not claim to be experts on any one area, more like integrationists. Where we have a little fun is that we poke at some of the poorer systems out there, and that's the grief you bumped into.

The reasons it "doesn't work" can be viewed at several different levels. For a start, you're using the wrong URL, and also a browser that grumbles when it sees the stylesheet on SSL mixed in with cleartext HTTP. Explain precisely what the browser is saying -- that it you there is a security breach in the Style sheet, and there's nothing wrong with the cleartext HTTP?

At another level, we can see that the software -- blogs in general and MT in particular -- just can't cope with HTTPS. They, perhaps like you, think that this is not a good place to use SSL, so get confused when we try. Also, Apache and your browser lack critical features in TLS, such as SNI, which make it possible to solve the cert problem.

At a third level, why does the protocol give us such grief? Why does it impose such difficulties? Why do you think I have to "get a proper cert" in order to use crypto?? Other well written protocols "just work" and HTTPS just causes grief.

You ask whether I have a clue as to where to use crypto. My clue is this: everywhere. A good crypto protocol should have only one mode, and it should be secure. HTTP and HTTPS fail miserably. Sorry, your browser only supports these really old broken protocols, so we have a mess. I hope you can see something -- a glimmering -- of that now!

Posted by: Iang at November 19, 2006 05:14 PM

Amen.

Posted by: Nudecybot at November 20, 2006 09:56 AM

I don´t know whether it´s easy, but the general rule of getting https right is to use relative pathes wherever possible:

Change

<link rel="stylesheet" href="https://financialcryptography.com/styles-site.css" type="text/css" />

to

<link rel="stylesheet" href="/styles-site.css" type="text/css" />

if possible. That way it should work both for http and https without problems.

Posted by: Best regards, Philipp at November 20, 2006 11:47 AM

Well, in my defense, I was right about one thing: your site is indeed misconfigured, whether deliberately or not. :)

Besides, it was my first visit to this site, cut me some slack.

Still, I notice that you changed the stylesheet reference in your code after I posted that comment, so the broken certificate warning disappeared (on the main page atleast, it still pops up on the comment pages).

If you were really trying to make some kind of point about broken HTTPS protocols, you wouldn't have touched a thing, yet you corrected it.

Anyway, I understand now from your comment above that you were trying to poke fun at poor protocols, but I have trouble following some of the points you are trying to make:

"For a start, you're using the wrong URL"

Well, what would be the right URL then? Both the HTTP and HTTPS URLs of the main page used to give warnings (before you silently modified your site in response to remarks from me and other readers).

"Explain precisely what the browser is saying -- that it you there is a security breach in the Style sheet, and there's nothing wrong with the cleartext HTTP?"

The browser says nothing at all about security or insecurity. All it says is that the site's SSL certificate cannot be verified (i.e. not signed by a trusted CA). I can paste a screenshot for you if you haven't seen the error message.

It is up to the user (i.e. me) to decide that lack of proper encryption is not relevant for this particular site, and that I can safely proceed. The concept of secure/insecure depends on the higher-level intention of the site, the browser just warns you about the low-level mechanics.

"Also, Apache and your browser lack critical features in TLS, such as SNI, which make it possible to solve the cert problem."

You are wrong on two counts here:

First, my browser (Opera) does support SNI. It's your server that is misconfigured.

Second, what is wrong with a protocol that is still evolving? Sure, Server Name Identification might not yet be a standard part of all browsers and servers, but it's getting there. Does that mean HTTPS is completely useless?

Also, SNI will certainly not eliminate the need for public key certificates signed by a trusted authority, if that is the "cert problem" you imply above.

It will only allow web servers that serve multiple virtual sites from a single IP address to know sooner which certificate to present to clients, before the HTTP Host: header is received and the handshake is over. It will only save you the trouble of getting a separate IP address for each SSL web site you want to host, that's SNI in a nutshell.

"At a third level, why does the protocol give us such grief? Why does it impose such difficulties? Why do you think I have to "get a proper cert" in order to use crypto?? Other well written protocols "just work" and HTTPS just causes grief."

Because security is a complex issue. HTTPS is not only a point-to-point encryption protocol, it's also an authentication protocol rolled into one.

You certainly don't need to "get a proper cert" to simply encrypt information, but you do need a certificate if you want any kind of protection from man-in-the-middle attacks (provided the top level CA's do their job properly, of course).

What exactly are these difficulties and grief that HTTPS supposedly heaps unto your shoulders? Are you talking about getting the certificate? The process is quite streamlined these days.

"You ask whether I have a clue as to where to use crypto. My clue is this: everywhere."

What is the point of encrypting information that is publicly visible?

In summary, I will grant that your mis-configured site was an attempt to point out perceived problems with HTTPS, but from your flawed (or atleast mis-stated) arguments above I'm still not fully persuaded that you are qualified to evaluate and discuss cryptography related issues, financial or otherwise.

Nevertheless, your SSL certificate atleast prompted interesting discussion from other readers, which might be enlightening to some. :)

Posted by: Grnch at November 21, 2006 04:49 PM

Grnch takes up iang's marvelous bait:

"The browser says nothing at all about security or insecurity. All it says is that the site's SSL certificate cannot be verified (i.e. not signed by a trusted CA). I can paste a screenshot for you if you haven't seen the error message."

We've all seen the screen, thank you. A CA "trusted" by whom? Why do you expect the user know or care about this or, even if they know and care, to agree that the CA is "trusted"?

What the screen really means is something very different than what it says: it means that organizations are dunning you for money for functionality (encryption) that you thought you had already bought. That is what CAs are for, not for the quite insignificant threat of "man-in-the-middle attacks." (The real middleman attack is phishing, which is attack against cognitive interpretation of the domain name. Phishing isn't and can't be solved by CAs).

"Because security is a complex issue."

Not in this case it isn't. Encryption is a remarkably simple idea from the user point-of-view. Instead what we have here is a tying scheme masquerading as security scheme. Requiring multiple transactions for what could simply be built into the software (as it is for example in SSH) is what creates the entirely gratuitous complexity.

"HTTPS is not only a point-to-point encryption protocol, it's also an authentication protocol rolled into one."

Really? Who or what is it authenticating, and why?

"What is the point of encrypting information that is publicly visible?"

Millions of web sites using HTTPS are not open to the general public. And for those like www.financialcryptography.com that are, there are various kinds of public visibility. If a website is encrypted, it is visible only to software that actually takes the trouble to go to the website and download the content. If it's not encrypted, a "vacuum cleaner" on a hub (such as the Chinese firewall) can read and filter it without having to bother with a separate connection to discover the content.

Perhaps you think this is a trivial distinction. I don't. And it should be the customer's privilege to make this distinction instead of having a high-cost tying scheme in the guise of an idiotic security scheme foisted on us.

Posted by: nick at November 21, 2006 11:23 PM

"A CA "trusted" by whom?"

Trusted by the browser developers, whom you already implicitly trust by using their software. If a CA becomes untrustworthy, it will disappear from the default certificate lists. If you disagree with the choice of CAs, stop using that browser.

Security boils down to networks of trust ultimately. You have to trust many things, including the browser and server developers, the party on the other side of the connection, etc.

"the quite insignificant threat of "man-in-the-middle attacks.""

Ignorant statement.

"Phishing isn't and can't be solved by CAs"

Of course not. But it is made ever so harder. Security consists of layers of difficulty for the attacker, not of a single silver bullet.

"Encryption is a remarkably simple idea"

I said security is a complex issue, you reply that encryption is simple... see the disconnect here?

"Requiring multiple transactions for what could simply be built into the software (as it is for example in SSH) is what creates the entirely gratuitous complexity."

That's your solution? SSH?

Try connecting to a host for the first time with SSH. You are told that the host's identity is not known, you are given a random-looking fingerprint of the host key, and you are supposed to decide on the spot. Let's say that the security of the transaction is very important to you. How could you possibly decide if the host is what it says it is, and it has not been redirected to a different machine by e.g. some less than ethical employee at your ISP?

Do you then proceed to call the company to give you the public host key out-of-band so you can verify the host identity? Do you try to determine that the person you called really represents the company, etc? Multiply this by how many HTTPS sites you connect to, you will do this for every one?

The CA basically does this process once, for you and everyone else, so you don't have to repeat it.

Is this certification process perfect? Certainly not, nothing is perfect. But then you try to compare it to SSH, which doesn't even attempt to solve the initial identity issue.

I will take a process that works Good Enough(tm) for the vast majority of retailers over nothing, thank you.

What would you propose as a replacement for HTTPS (or SSL/TLS on which it relies)? Comparisons with SSH are beyond ridiculous.

"Really? Who or what is [HTTPS] authenticating, and why?"

See above.

"If it's not encrypted, a "vacuum cleaner" on a hub (such as the Chinese firewall) can read and filter it without having to bother with a separate connection to discover the content.
...
And it should be the customer's privilege to make this distinction instead of having a high-cost tying scheme in the guise of an idiotic security scheme foisted on us."

If you need only the encryption part of HTTPS, for e.g. foiling the Chinese firewall (a legitimate reason), absolutely nobody is preventing you from using a self-signed certificate, and you don't have to pay a single cent to any CA.

Your Chinese users will simply have to install your certificate into their browsers on the first connect, and there will be no warning next time. You get the exact same functionality that SSH provides, i.e. a warning on first connect, and registration in ~/.ssh/known_hosts so there is no warning on subsequent connects.

So, in the above example, where is this "idiotic" security scheme that is somehow being "foisted" upon you by the CA's?

HTTPS (actually SSL/TLS) is a complete superset of SSH in terms of functionality, and the third-party identity management part is completely optional if you don't need it.

Again, what exactly is wrong with HTTPS/SSL/TLS, and what would you replace it with? Replacing it with SSH (a subset) is not exactly a step forward, is it? If you have a better solution, I'm all ears.

Posted by: Grnch at November 22, 2006 06:59 AM

Hey Grnch ... keep up the good work!

> Still, I notice that you changed the stylesheet reference in your code after I posted that comment...

Guilty as charged! Yes, after Philipp's suggestion, I found it in the style sheets and then was able to configure that through the MT page editor feature. As I was doing it on the run, I omitted the bug fix report :) Thanks for your prodding.

> If you were really trying to make some kind of point about broken HTTPS protocols, you wouldn't have touched a thing, yet you corrected it.

OK, point. To explain: The major part of the "point" is located at http://iang.org/ssl/ ... if you are still sane after that, feel free to post ;)

This website on HTTPS is a smaller part of the point: Although I criticise the SSL world, I also run a HTTPS blog, in support of fixing HTTPS. For about 3-4 years, we have been engaged in a fairly complicated and broadly spread campaign to address security weaknesses in something euphemistically called "secure browsing." Skipping that long story, an essence of being serious about this campaign is that we should run websites using SSL. That is, eat our own dogfood.

That doesn't mean that we have to make you, the reader, uncomfortable, but I at least have to suffer the pain of SSL websites if I am to write about Phishing.

> Well, what would be the right URL then?

Exactly. There should only be one URL. Security concerns dictate that there should be one security system, and that's the one to use. An unfortunate historical accident of SSL's past meant that there are two URLs. In that case, one will always be wrong, and both will open up security problems.

(But, precisely, the HTTP is a hack for those who cannot do the SSL stuff at all because of their software. E.g., RSS readers and the like...)

> It is up to the user (i.e. me) to decide that lack of proper encryption is not relevant for this particular site, and that I can safely proceed. The concept of secure/insecure depends on the higher-level intention of the site, the browser just warns you about the low-level mechanics.

Yeah, we and the original designers wish that were possible. Unfortunately, that came from a pre-Internet age, perhaps from military thinking. It can't apply to 99% of the net, because they don't know what you are talking about. Hence, if we want to deliver security, we should consider what I mentioned before: "there is only one mode, and it is secure!"

At the more practical level, I agree that the security model of secure browsing is based on that concept of "share info with the user." The problem with this is that browsers today do not share the info. So the model is broken. So we have phishing.

We have a choice. Either we share the security info or we move to security delivered in a simple world. Browsers don't do the former, and won't do the latter. Any other choices? Oh, yeah, EV :)

> my browser (Opera) does support SNI. It's your server that is misconfigured.

Guilty as charged. I tried to find someone at Apache to help, but failed.

More later...

Posted by: Iang at November 22, 2006 10:42 AM

Ladies and gentlemen,
This was a very educational discussion. The best solution I have seen to https misery (https adds insult to injury on top of ssl) is what webmoney does, so I use it for my own commercial website ( http://defense.4242.hu ).

Here are the principles in a nutshell:

1. Don't use self-signed certs. Instead, roll your own CA key and sign your server cert with it. The CA cert will be self-signed, of course.

2. The front page should be plain http with a warning that for using the website you should first download the CA's certificate. A link should be provided to the CA cert, which is also supposed to come from http. Make sure the mime type is correct.

3. All the links on the front page (except the one to the CA cert and the ones to inline elements and stylesheets) should point to the https site.

This achieves the following:

1. The "brave and impatient" will have the usual warning about not being signed by a trusted CA, but they'd ignore it anyway.

2. The "paranoid but ignorant" that believe what they see and follow all instructions to the letter will get no warnings at all. Instead, they will be reinforced in their belief that we take security seriously (which we do).

3. As an added benefit, you can re-use the CA key and have a whole bunch of HTTPS websites with certs signed with it. Once a user decides to trust the CA, the browser stops complaining.

0. All the important communication will happen in HTTPS.

P.S.: What happened to SHTTP? I miss it soooo much...

Posted by: Daniel A. Nagy at November 23, 2006 07:43 AM

Name:


Email Address:


URL (preferred, hides Email):

Remember personal info?
YesNo
Comments:




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