On Sat, Dec 7, 2013 at 3:21 PM, Tobias Gondrom <[email protected]>wrote:
> On 07/12/13 15:06, Ralf Skyper Kaiser wrote: > > Hi, > That is open for discussion. My personal preference is that server > announces a set of 'STRONG' ciphers > to the client. The client will fail to connect on future connections if > none of the announced ciphers is no > longer available (downgrade attack under way). > > > [...] > > Maybe one question: as the browser already has the information about all > cipher suites offered in a TLS connection and could possible cache this > information from previous connections already without pinning. Would > pinning this via an http header or file add much value over this? > > What do you think? > > My feeling is that the server should announce to the client that CIPHER-SUITE-pinning is supported. The client should only pin the cipher suite if it has been announced by the server (similar to certificate pinning). Using the cache to determine which cipher to use might not be sufficient. The ServerHello only contains 1 cipher that the server picked from the ClientHello. In this case the server admin would have no chance to upgrade to a stronger cipher. Instead the server should send a list of 'preferred strong ciphers' to the client. If the client (TLS connection) is not using any of these ciphers then the connection should fail. If the client uses one of these ciphers then the client should pin the 'preferred strong cipher' list. The pinned list should be updated on every successful connection. For future communication the client should fail the connection if the negotiated TLS cipher is not part of the pinned ' preferred strong cipher' list. This would allow the server admin to add new and stronger ciphers to the list and slowly remove old or broken ciphers. regards, ralf
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
