« November »
SunMonTueWedThuFriSat
    123
45678910
11121314151617
18192021222324
252627282930 
       
About
Categories
Syndication
Locations of visitors to this page

Powered by blojsom

Radovan Semančík's Weblog

Thursday, 15 November 2007
« OpenID Dogfight | Main | Wrong Trust »

HTTPS should stand for "HTTP Secure". But how secure HTTPS really is? And how secure are the applications that rely on HTTPS?

HTTPS is based on SSL. Based on my basic cryptology knowledge I can believe that the mechanisms of SSL protocol as well as commonly used cryptosystems are secure. The problems seems to be on higher layers: in the servers, browsers and in the applications.

Servers send X.509 certificates during HTTPS connection setup. Browsers use the Common Name part from the certificate to check agains the host part of URL (wich is DNS name). The browsers also checks that the server's certificate is issued by any of the "trusted" certificate authorities configured in the browser.

Now, if I use the "https://www.mybank.com/" and I see the page and there is no warning, what does it really mean? Almost nothing. Nothing that I would really trust. Why I'm considering that untrustworthy? To explian that you have to know how the X.509 certificates for HTTPS purposes are issued.

Certificate authorities are expected to issue certificates that have Common Name (CN) property set to the value of the correct host (which is www.mybank.com in our case). The only thing that the certificate authority can check is if the guy that is asking for the certificate is an owner of the appropriate DNS domain (for example by checking RIPE Database). It can request some papers from the organization stating that it really exists. And that's it. The certificate is issued.

Now, how difficult is to twist that? You can legaly register a similar DNS domain, something like my-bank.com, mybank-access.com, mybank.cc. Then you get the certificate legaly. And how does users know if the correct domain is mybank.com or my-bank.com? Or I can just pretend that I want to get certificate for mybank.com and falsificate the papers. How could the CA based in USA check the papers (that seems to be) issued by the government of South Uzbekistan? There were approx. 40 certificate authorities pre-configured in my Firefox. I would bet that at least one of them will issue a certificate based on some barely readable fax message showing (seemingly) valid legal document. And this certificate will be "trusted" by the browser. In fact the browser with default setting will not distinguish between the certificate from the lousy CA and the most secure certificate from Verisign.

Some banks are asking users to check the fingerprint of the certificate at the beginning of each access. The funny thing is that they provide "authoritative copy" of the certificate fingerprint on the page that is protected by certificate that has to be checked. Or do they really expect users to remember the fingerprint? And to check it on each access? No. It is just CYA, not a security measure.

Now consider that the prevailing Internet appliction security mechanism is authentication by passwords over HTTPS channel. How secure the Internet applications (including Internet banking applications) really are?

The scary thing is that there are "identity systems" (see previous post) that rely exclusivelly on HTTPS ... Shouldn't we rather stop the nonsense, stand back, take few deep breaths and start thinking and talking how to make it all right this time?

Posted by semancik at 8:21 PM in security
Comment: Juraj Bednar at Thu, 1 Jan 12:00 AM

I actually tried getting certificates from american CAs back in 2003. Here's my experience: http://flz.sk.cx/CA

Add your comment:
(not displayed)
Generate another code
SCode

Please enter the code as seen in the image above to post your comment.
 
 
Your comments will be submitted for approval by blog owner to avoid comment spam. It will not appear immediately. Also please be sure to fill out all mandatory fields (marked by asterisk). This ... ehm ... imperfect software does not have any error indication for missing input fields.
 
 

 

[Trackback URL for this entry]