[cryptography] ssl/tls splicing attack

Chris Palmer chris at noncombatant.org
Sun Mar 21 15:49:03 EDT 2010

James A. Donald writes:

> user is overwhelmed by hideously lengthy globally unique true names,

You get that the browser's notion of an "origin" is the security-meaningful
unit of naming, right? So the path, query string, fragment, et c. need not
be displayed with equal and confusing prominence --- they impinge on
security only in that they can be used to confuse people about the part of
the name that the browser makes its security decisions on.

So, browsers can communicate to users better. There is a lot of room for
improvement in secure UI.

> > 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.

Does legend cite any sources?

The round-tripping is amortizable and minimizable, and most sites I work on
pay a huge content-layer bloat-price with or without HTTPS. There is usually
tons of room for improvement at the content and HTTP layer, and some people
still haven't heard of TLS session resumption, even. It is definitely
possible to improve both security and performance in most applications.

The few apps that are already as good as they can be at the content layer
tend to be at Google or Yahoo. Is it any surprise it was Google that came up
with SPDY? It doesn't even make sense to optimize the lower layers until you
clean up the upper layers, and basically nobody is aware of upper layer

I gave a talk on this topic last year:




> Usability mailing lists are full of morons, because any idiot thinks
> he understands usability, whereas most idiots realize they do not
> understand cryptography.   They are also full of marketroids, who are
> worse than idiots, because idiots speak what they think it the truth.

I take it you will not be joining the secure browser UI conversation. That
is ok.

> Further, the browser vendors well not hire us because cryptography is
> a market for silver bullets, where neither purchasers nor vendors know
> if what is being sold any good.

Speak for yourself. I am proposing to deal with the UI, because cryptography
is not our problem. One of the nice things about usability engineering is
that it is considerably more quantifiable than security. (We don't know how
many vulnerabilities there are, but we can know how many people were able to
buy the book they wanted on Amazon in 10 minutes given a browser and a
credit card.)

> Further, the present architecture of browser security (cryptographically
> ensuring the validity of the displayed globally unique true name) is
> locked in by the income model of everyone involved (being paid to manage
> globally unique names)

How are browser vendors beholden to CAs? To DNS registrars?

More information about the cryptography mailing list