[Cryptography] Is it time for a revolution to replace TLS?

[John Denker]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This thread has generated a lot of good discussion.  In contrast, 
to my surprise, the recent thread on "forged SSL certificates" was 
only one message long.

On 05/02/2014 05:10 PM, Jason Richards wrote:
> Paper from Carnegie Mellon and Facebook: Analyzing Forged SSL
> Certificates in the Wild: https://www.linshunghuang.com/papers/mitm.pdf

>     We analyzed 3,447,719 real-world SSL connections and successfully
>     discovered at least 6,845 (0.2%) of them were forged SSL certificates.

In the same vein, the previous MITM thread was only one message long:
On 09/10/2013 08:31 AM, Perry E. Metzger wrote:
> The story has been floating around for some days now. Apparently, Man
> in the Middle attacks have been used quite extensively, including
> against the Brazilian state oil company, and a major international
> wire transfer network.
> 
> http://www.slate.com/blogs/future_tense/2013/09/09/shifting_shadow_stormbrew_flying_pig_new_snowden_documents_show_nsa_deemed.html
> 
> I think this indicates that Certificate Transparency and similar
> techniques need to be deployed quickly. CAs have been dead as a
> form of real assurance for some time now, but at this point the dance
> party on the grave has gone on a bit too long.


1) There is a connection between these three threads.  It seems 
to me that 6845 forged certificates is 6845 too many.  It is proof 
that TLS has failed in its primary mission.

In the words of John Oliver, "Why is this still a thing?"  Why is
it even remotely possible for forged certificates to be found in
the wild?

2) IMHO the first step should be to ask, what would it take to
create some semblance of security?  Preventing MITM attacks is 
high on the list of requirements.

*) If this can be achieved by non-revolutionary fixes to TLS, then
 the answer to the question posed by the Subject: of this thread
 is no, we don't really need a revolution.  We can make repairs in
 the short run, and re-implement whatever we like in the long run.

*) OTOH if security cannot be achieved within TLS, that proves we
 do need a revolution.

3) Following up on the previous point:  For many many years we have
known how to do zero-knowledge password checking ... but the browsers
don't do it.  This is relevant because it would make life much
harder for the certificate forgers.  Apache supports "basic auth"
and "digest auth" which have no resistance to MITM attacks.  Why 
not support something that actually resists attack?  This would 
not require a revolution.

As mentioned in the Huang paper cited above, javascript doesn't have 
access to TLS keying information.  This means that if somebody wanted
to implement password-authenticated key exchange in javascript, they
couldn't do it.  This is a fixable problem.  It would not require a
revolution.  I suppose it would be considered a "layer violation" 
which is inelegant, but IMHO having passwords stolen by the MITM is 
a lot worse than inelegant.

This doesn't solve all the world's problems, because the MITM
could be fiendish enough to send bogus .js code ... but it would
be a step in the right direction.

4) One the other (server) end of the connection, /pinning/ would
make things a lot harder for the forgers.  Right now SSL depends
on authorities with no pinning, whereas SSH depends on pinning with 
no authorities.  It seems cloyingly obvious that things would be
more secure if we insisted on at least two forms of authentication. 
For example, if the First National Bank of Dogpatch wants to start 
using a new certificate, it should be signed by the old certificate
/and/ by a reputable CA ... and perhaps notarized by a third party.

On 04/18/2014 10:22 AM, Tony Arcieri wrote:
> We have at least 4 contests here, I think:
> 
> 1) Better transport encryption (Tcpcrypt is already tackling this)
> 2) Better key exchange (Tcpcrypt is also tackling this)
> 3) A better certificate format
> 4) A better system for authenticating/revoking keys (e.g. Convergence,
> Tack, CT)

5) That's a nice list.  We agree it doesn't make sense to insist 
on a one-size-fits-all solution.

In particular, I can imagine multiple security schemes within a 
single connection ... with varying /degrees/ of trust.

For example:  I contact port 443 on the non-virtual server at a 
certain IPv4 address.  This connection needs to have "some" degree
of security at this point, before I even send the URL ... because 
I would prefer not to send the URL in the clear.  As a second stage,
the URL refers to a virtual server, and after I have sent the URL
the security should pivot to something specific to virtual server.
Thirdly, the virtual server asks for my password.  At this point
we can do some sort of zero-knowledge password-authenticated key
exchange, and the degree of security is now higher.  Some of this
could be done by layers of superencryption, but some of it could
be done more efficiently by a succession of hand-offs.

6) Has anybody seriously checked the design and/or implementation of
the convergence plugin?
  http://convergence.io/

The .xpi download is not signed in any way AFAICT.  That forces one
to wonder whether they are serious about security.

How do we know the convergence.io site is not a wholly-pwned subsidiary
of the FSB or NSA or whatever?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIVAwUBU3J6HfO9SFghczXtAQKXcQ/8CynhpYJVD0AhepZTw0Wt86PnaWYyBco/
WhrYJPFQqPVlYp+zfs4TZsZTlRaYx5YBFzaHBeA/Uz1Ri1s2tFfcUqGYD9KwNrij
rrUs3XWZY8UZ8WBwvWHlQQ11WS14hgE83JJP/lF9E6iEvxav+8qtvAiqG31shxOT
eb/nkIEI98X5bXVejXND6Fk4AEqGfYKDgXH9Xq1xbF6g3upkW7J2RRhQtjMcWMBu
k6LY9ij/1LVqTCp/Hyqp/Rc8B7+NHm0W0TLmsSVKkKDwfTiZ5L6HbLJteSe8YPfK
ySHBNMVADhAjgC5UaTsci7chdw22BBpdyQ1VgZoSA85EbspUKvhTMHjTFHc6D5ux
Dp72xnweG5zYU9A4SLOOcXj+rA4niI7w4HPpomsUM3wP/F9bxhJh2mwx0UAMfxVz
Vw069rfmHKrN5GJhPQ0HfUOh4CXzBHXOYobM36cMoRjJXx//23YOU451XZTSRfmM
WxJm6Uwxr3nCuCEQhrGl9Vy9rbhrCovpA+UDyHjfwF7Z4dEepSf9Cn2ROvSPto7I
dOqsfHFe7zb3xdXDFRwvjeAoTuxWcuvIrSQBqjleV5CR9JFfTOeUfg6kfOoXoRpN
OtohhVhNBW1yX6TyiWBnc2uBgcEtPpwghnMUKc6j8PeH3Q+0aKg8sWlmgh2TuFPP
IyrKu8L1B8E=
=rUv/
-----END PGP SIGNATURE-----