[cryptography] ssl/tls splicing attack

James A. Donald jamesd at echeque.com
Wed Mar 17 03:22:49 EDT 2010


On 2010-03-17 2:34 PM, Chris Palmer wrote:
 > As soon as someone creates a fully working and wonderful
 > WEP/WAP/link-layer gadget, we'll all complain that we really need
 > end-to-end security anwyay, because we do.

Indeed we do - and https is in theory end to end, were it not that the
user is overwhelmed by hideously lengthy globally unique true names,
and were it not for the fact that there is no reliable back channel
whereby the web site can send a message to the end user and the user
can be assured it comes from the entity with which he has a login
relationship.

However, unknown neighbors swiped the majority of my bandwidth until I
switched from WEP to WPA2.  Unlike ninety nine percent of WPA2 users,
I use a password generated to have 120 bits of entropy.  And whenever
I travel, I swipe other people's bandwidth, though not in such
immoderate amounts.  So it really does matter that even the best Wifi
is subject to offline dictionary attack.

 > Any reason you didn't list SSH v2 as successful deployed
 > cryptography?

The average user uses wifi and https and does not use ssh.

 > Origins are still tricky for people to understand, but in their
 > common form, e.g. https://www.wellsfargo.com, they are not *that*
 > weird.

There is nothing wrong with wellsfargo.com as globally unique true
name, but sitekey.bankofamerica.com is a problem, and even if everyone
had nice short simple globally unique true names (which is logically
impossible, since the world contains so many entities) what is
displayed is not the origin, but the resource name, which is always
horrible, which deters people from parsing the resource name to find
the origin name.

Not only do most end users not understand about origins, most people
who develop banking websites do not understand the security
implications.  Observe that the entities on my website
(http://jim.com) almost always have short meaningful names even though
it has absolutely no need for security, whereas resource names on bank
sites are invariably lengthy gibberish, obscuring any shenanigans with
the origin part of the url, and deterring the end user, including
sophisticated end users like myself, from looking at the origin.

People just are not going to look at even a short meaningful origin
name when it is part of long meaningless string of gibberish.  I will
not, and if I will not very few ordinary users are going to.

 > The biggest security problems are in UI and in browser policy right
 > now. (And maybe the presistent belief among developers that HTTPS is
 > "slow" "because of all the crypto".

It is slow because of additional round tripping.  Legend has it that
for each additional round trip, you lose twenty percent of market
share.

When you have an https web page, which accesses lots of https scrips
from all over the place, you get painfully many round trips, and the
page is irritatingly slow.  This is obvious on many banking sites,
more so when accessing them from overseas.




More information about the cryptography mailing list