|
|
Log in / Subscribe / Register

Laurie: Improving SSL certificate security

Laurie: Improving SSL certificate security

Posted Apr 3, 2011 11:38 UTC (Sun) by tzafrir (subscriber, #11501)
In reply to: Laurie: Improving SSL certificate security by drag
Parent article: Laurie: Improving SSL certificate security

There are quite a few "new times". Just send out many phony messages, and hope you meet someone with a blank history on the current client. E.g. on an internet cafe.

The method of ssh simply ignores the problem altogether. It's not really useful. You might as well educate users to accept self-signed certificates. It's basically the same.


to post comments

Bingo

Posted Apr 3, 2011 14:30 UTC (Sun) by khim (subscriber, #9252) [Link] (4 responses)

The method of ssh simply ignores the problem altogether. It's not really useful. You might as well educate users to accept self-signed certificates. It's basically the same.

Bingo! Self-signed certificate is exactly right solution. My bank uses "green bar" for normal people, but for large clients (you know, the ones who transfer millions around) they use self-signed certificate. How come? Easy: they give you paper instructions in sealed envelope (which you get in bank personally), it contains fingerprint, etc. If you don't see the "unknown certificate" window - it's fraud, if you see the window and certeficate does not match - it's fraud, if you ever see the window again - please call the bank and you'll get another sealed envelope if the certificate is really changed.

All these talks about "side channels" are missing the point: in most cases where fraud may deprive you of sizable sum you already have a "side channel" - you just need to use it.

Bingo

Posted Apr 3, 2011 15:29 UTC (Sun) by drag (guest, #31333) [Link] (2 responses)

> There are quite a few "new times". Just send out many phony messages, and hope you meet someone with a blank history on the current client. E.g. on an internet cafe.

If a user is carrying about banking stuff via internet cafes there is NO effective way to secure it. Bringing something like that up is just silly.

> Bingo! Self-signed certificate is exactly right solution. My bank uses "green bar" for normal people, but for large clients (you know, the ones who transfer millions around) they use self-signed certificate. How come?

People that transfer 'millions' around are generally businesses. Financial institutions use insecure FTP connections or SFTP (ssh) with a throw away user account. They don't actually get real Unix accounts with vsftp or openssh most of the time. It's just some Java program that provides support for multiple protocols to suite the purposes of the client.

Actual security is provided through PGP encryption/signing of the files being transfered. The protocols used to transfer the files are not trusted.

If it's 'realtime' style connection they will use things like FIX or FIXML connection on a dedicated data line (or at the least a IPSEC tunnel) were all traffic is logged and monitored.

> All these talks about "side channels" are missing the point: in most cases where fraud may deprive you of sizable sum you already have a "side channel" - you just need to use it.

It would solve the biggest threats to average consumers which are going to be things like Phony websites with fraudulent SSL certs and XSS attacks.

Consumer banking, to put it bluntly, are incompetent at designing website applications. They do a shitty job and can't be trusted.

Bingo

Posted Apr 3, 2011 16:31 UTC (Sun) by paulj (subscriber, #341) [Link]

Agreed. Indeed, I've seen *email* used to transfer files whose *content* were worth literally millions of Euro (the data itself - not transferring money between accounts). Secured, just as you say, with PGP.

Bingo

Posted Apr 3, 2011 18:29 UTC (Sun) by jthill (subscriber, #56558) [Link]

Actual security is provided through PGP encryption/signing of the files being transfered. The protocols used to transfer the files are not trusted.
Not to detract from your point, but I think it's worth highlighting that SSL itself is equivalent to PGP. Browsers use a precanned trustdb, but it's the quality of the trustdb the browser vendors deliver that's in question here. Any precanned PGP trustdb will be just as vulnerable, in exactly the same ways. Phil Zimmerman (et al.) was right, a WoT is the only acceptable substitute for personal verification. That's what Google is trying to implement, without making anybody admit it in so many words.

Bingo

Posted Apr 3, 2011 16:56 UTC (Sun) by jthill (subscriber, #56558) [Link]

I'm having a good time remembering the FUD-storm the CA's kick up when anyone tries telling this little home truth in public. It came up on /. a year or so ago and the professional confusers were out in force.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds