[cryptography] ssl/tls splicing attack
James A. Donald
jamesd at echeque.com
Sun Mar 21 17:12:00 EDT 2010
James A. Donald writes:
> > user is overwhelmed by hideously lengthy globally unique true
> > names,
On 2010-03-22 5:49 AM, Chris Palmer wrote:
> 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.
Yes there is, but there is no way around the fact that globally unique
true names are inordinately numerous, and the fact that their length
is often excessive is merely a reflection of this fact.
People, in conversation, and when using aliases on their buddy list,
refer to each other by quite short names, of which a very limited
number of names are acceptable. That reflects the natural limits of
human managed namespaces.
>>> 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?
That is why I call it a legend. I believe it to be at least half true, but
can find no concrete support.
> The round-tripping is amortizable and minimizable,
Yet bank sites are irritatingly slow.
> some people still haven't heard of TLS session resumption, even. It
> is definitely possible to improve both security and performance in
> most applications.
Which implies that most actual applications have security flaws and
> 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?
The fact that SPDY is needed implies we have a round trip problem.
The problem that SPDY addresses is that first we have a lot of round
trips to set up a secure connection for the page, and then we have a
to request more bits and pieces, then a lot more round trips to set up
connections for all the bits that are included in the page.
SPDY, by pushing all the needed parts of a page over a single
connection without waiting for requests, reduceds round trips to the
minimum possible with SSL - but the minimum possible with SSL is still
> I gave a talk on this topic last year:
Bank sites are still horribly and unnecessarily bloated. Have you
made any consultancy money fixing them? Have the offenders
paid you to remedy the problem?
>> Further, the browser vendors will 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.
My original post was on the point that all our security problems are
because users cannot use security - but a major part of this problem
is that globally unique true names are inherently hard to use.
>> 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
There are no browser vendors. Browsers are given away. They are
funded by people who wish to influence web architecture - among them
people who sell servers like Microsoft and certificates and domain
names, such as Verisign. Google's influence is probably the least
corrupting, since they are in it to support their cloud services, which
somewhat aligns their interests to those of users, but Google is an
anti privacy influence - they like to log everything, mine the data, and
More information about the cryptography