The key pinning is a very good step in the direction of web security. However, it does raises the operational bar for web sites and is not helpful with new installations.
Yet the observation here is that the reliable security is especially important for sites that authenticate the users. So why not to use the passwords that users have to verify the certificates? SRP [1] or J-PAKE [2] protocols allows *mutual* authentication of both client and server based on the shared secret. RFC5054 [3] even describes how to use SRP in TLS Authentication. The problem with these protocols is that they assumes a side channel for the distribution of the shared secret. In practice this translates into supporting both certificate-based HTTPS for the initial user registration and the new protocols for authenticated user sessions. This is rather costly operationally and perhaps the reason while the protocols remains outside mainstream browser/server implementations. Hence the suggestion to allow to use SRP/J-PAKE *only* for certificate verification. The idea is to provide hard to spoof yet customizable GUI in the browser where the user can assume that entering a password there is always safe. The browser then performs secure authentication using ordinary HTTP PUT requests. If it is OK, it uses the newly established encryption channel to verify the certificate for the subsequent connection. After that a normal HTTPS connection resumes. Compared with RFC5054 the key difference is that the server side in this case can be implemented as a part of web application without any changes in the server software/hardware to support the new protocol. This is possible as the authentication happens only once per session so computationally expensive J-PAKE/SRP exchange happens rarely and deployment of accelerators can be avoided even on busy sites. [1] http://srp.stanford.edu/ [2] http://en.wikipedia.org/wiki/Password_Authenticated_Key_Exchange_by_Juggling [3] http://tools.ietf.org/html/rfc5054 _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
