User: Password:
|
|
Subscribe / Log in / New account

Transport-level encryption with Tcpcrypt

Transport-level encryption with Tcpcrypt

Posted Aug 29, 2010 16:37 UTC (Sun) by Tet (subscriber, #5433)
In reply to: Transport-level encryption with Tcpcrypt by blitzkrieg3
Parent article: Transport-level encryption with Tcpcrypt

If you see the little locked icon in your address bar, you should sleep easy in the knowledge that the only other party to view your communications was the web site

Utter nonsense. Yes, that's supposed to be how it works, but in the real world, it's simply not true. The obvious example is 3-D Secure, as used by banks here in the UK (and elsewhere?). You go to a web site, fill your cart and go to the checkout. You enter your credit card details, because the lock icon is present and you're confident that it's not a scam site. Then you're sent to a secondary authentication page. The lock icon is still showing everything's good. But what you're seeing is actually an iframe pointing to an entirely different site (in my case, hopefully it's LloydsTSB ClickSafe). But the padlock icon has nothing to do with this site, and thus offers no guarantees that the connection is secure, or that the page is being served by an entity that you trust. As a technically adept user, I can (and do) explicitly check the certificate of the iframe. But I'm in a very, very small minority. It's trivially easy for a phishing site to show a valid padlock throughout the entire transaction.


(Log in to post comments)

Transport-level encryption with Tcpcrypt

Posted Aug 29, 2010 17:52 UTC (Sun) by foom (subscriber, #14868) [Link]

That is how it works.

The padlock is shown on the outermost site. It is up to that site to ensure the security of its own website against XSS, against hacking of its servers, and against using insecure content inappropriately. It's their responsibility, not yours, to make sure they use secure iframes not insecure ones. And your browser checks the certificate to make sure that it *actually* belongs to the site that your bank trusted. So no, you don't need to verify every iframe individually.

Okay, so it's not literally true that "the only other party to view your communications was the web site", it's the web site and other web sites that the web site trusts.

> It's trivially easy for a phishing site to show a valid padlock throughout the entire transaction.

Of course, but that has nothing to do with the rest of your complaint. In the case of a phising site, "the web site" that the user is visiting, and which is protected, is the phising site.

Transport-level encryption with Tcpcrypt

Posted Sep 2, 2010 8:47 UTC (Thu) by eduperez (guest, #11232) [Link]

That is why my bank refuses transactions if their website is displayed inside an iframe.


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