Alex Alten wrote:
SSL seems to be hanging by a thread, mainly the name to public key mapping
depends on how thorough the checking is done in to SSL vs application
layers
inside of the web browser. If this is hosed then unrestricted MITM is
in the cards
sometime in the near future.
re:
http://www.garlic.com/~lynn/aadsm27.htm#29 A secure Internet requires a secure
network protocol
i.e. we were called in to consult with this small client/server startup that
wanted
to do payments on their server. they had this technology they called SSL ...
and we
had to end-to-end process audits ... including walk-thru of some of these new
business
entities that were calling themselves certification authorities.
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
the fundamental SSL design point was that the user knows the relationship
between a website
and a URL, the user entered that URL, and SSL would authenticate that the
website that
the user *thot* they were talking to (from entering the URL), was in fact, the
website
they were actually talking to.
these days, most users have no cognition about relationship between websites and URLs,
they click on something in email and/or webpages. In this scenario, the attacker
is providing the URL and then the only thing that SSL is providing is
authenticating
who the attacker is claiming to be (via the URL that the attacker provides).
the original SSL design point had implicit assumptions that users knew the
relationship
between the website they thot they were talking to and URLs (and then SSL
authenticated
the relationship between those known URLs and the website). For the most part
those
assumptions are no longer valid ... which then breaks the security model and
all bets
are off. With the potential attacker frequently providing both the URL and the
website,
then the only thing SSL is providing is authenticating the website that the attacker
claims to be (via the URL) is the website that they are (breaking original basic
assumption about SSL). This totally invalidates the assumption that SSL is proving
that the website that the user *thot* they were talking to (via directly entering
the URL) was, in fact, the website that they were talking to (aka the user has
no idea what website they are talking to ... because they no longer have the
knowledge
about the relationship between websites they think they are talking to and the
URLs
for those websites).
The (*URL*) name to key mapping isn't the problem ... that is the mechanics that
SSL provided. The problem was that SSL security had implicit assumption that the
user knew the mapping between the website they think they talk to and the URL
for
that website. In the current environment, that assumption is no longer valid,
So the basic, most common PKI infrastructures provide a trusted public key
repository
(typically manufactured into browsers before they ship). Users are
indoctrinated that
they can trust those public keys ... for the purposes of digitally signing
digital
certificates. These digital certificates provide the binding between URL
(actually
the domain names part of URL) and website public keys. It is imperative that the
user (knowledge) then provide the binding the website they think they are
talking
to and the URL. That is the part that is missing in today's environment (and
what
large numbers of attackers can leverage to slip thru the "cracks").
The missing piece is trusted binding between who the user's think they are
talking
to and the URL (or at least domain name). This could be accomplished by a
separate trusted repository ... names that the end-user relates to and trusted
binding between those names
and URLs. Attacker provided URLs that are clicked on ... then can be
cross-checked
with things in that new trusted table (analogous to the way that the browser
table
of certification authority public keys are trusted).
Then the issue is that if there is a trusted table mapping names to URLs (or at
least
domain names) ... and a separate table of trusted public keys ... the whole
thing
could be collapsed into a single table ... totally eliminating the level of
indirection provided by (redundant and superfluous) PKI and certification authorities
... just add the public key to the trusted table of names & domain names (aka URLs).
The issue isn't so much that SSL is broken ... it is the implicit dependency on
users knowing the relationship between the website they think they were talking
to and the URL for those websites. Creating a user trusted table of website/urls
(analogous to the browser trusted table of certification authority public keys),
can make PKIs and certification authorities redundant and superfluous ... since
in whatever trusted process is used to maintain the trusted table of
website/urls
... can also directly include the public key for those website/urls.
this is similar, but different to some of the domain name infrastructure
proposals that
would allow real-time retrieval of on-file, domain name public keys (also making
PKIs and certification authorities redundant and superfluous). Some past posts
discussing catch-22 for PKI infrastructures with real-time domain name
infrastructure
public keys
http://www.garlic.com/~lynn/subpubkey.html#catch22
other posts about certificate-less public key operation
http://www.garlic.com/~lynn/subpubkey.html#certless
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
