Announcing SPDY draft 2 implementation in nginx

Re:Announcing SPDY draft 2 implementation in nginx by mtgx on Friday June 15, 2012 @01:56PM (#4117755)

The other article on SPDY complained about it having SSL enabled by default. Is that really something to complain about? Isn't it one of the good things about it, because if SPDY gets adopted, it means everything becomes encrypted? And isn't that a very desirable future?

[ Parent | on HN ]

Re:Announcing SPDY draft 2 implementation in nginx by e1ven on Friday June 15, 2012 @02:14PM (#4117835)

Having things encrypted is good, yes, but requiring people to get a certificate means that the web has fewer chokepoints, which is bad.

IMHO, SSL ought to use a fingerprint-comparison check, instead of a central cert. "This server has changed since last time. Is that OK?"

[ Parent | on HN ]

Re:Announcing SPDY draft 2 implementation in nginx by X-Istence on Friday June 15, 2012 @09:36PM (#4119599)

http://www.imperialviolet.org/2011/06/16/dnssecchrome.html

Using DNSSEC we can host the fingerprint of the cert in DNS at which point an CA is not required.

[ Parent | on HN ]

Re:Announcing SPDY draft 2 implementation in nginx by caf on Saturday June 16, 2012 @08:28AM (#4120486)

How is that a question that any end-user could be expected to answer with any kind of authority?

[ Parent | on HN ]

Re:Announcing SPDY draft 2 implementation in nginx by blaenk on Friday June 15, 2012 @05:41PM (#4118854)

What about the first time the user connects, how would they be assured that the fingerprint really is the site's and not a man in the middle?

Honest question, myself being pretty new to cryptography.

[ Parent | on HN ]

Re:Announcing SPDY draft 2 implementation in nginx by e1ven on Friday June 15, 2012 @05:44PM (#4118869)

In theory, you could do an out-of-band comparison.

In practice, you'd generally accept that the first one you receive is valid, and then watch for deviations from there.

This is the way SSH works, for instance.

[ Parent | on HN ]