Monday, 4 May 2015

Public Key Pinning Boosts Website Security




In the effort to mitigate man-in-the-middle (MITM) attacks, which uses fraudulent SSL certificates, the Public Key Pinning Extension for HTTP (HPKP) has been designed, in order to create a more reliable method of approving a Web server's digital certificate. HPKP permits a site administrator to put up a certificate authority's (CA) public key or certificate to their server's certificate and send the data in an HTTP header. This enables browsers and other apps to see that a server's certificate is approved and signed by a specific whitelisted CS, rather than depending on a chain verification certificate to validate it. The certificate verification stage of the connection is used to carry out the check, prior to any data being sent by the browser.


Google Chrome has been supporting Public Key Pinning for some time now and it has helped in detecting fraudulent SSL certificate issued by DigiNotar, employed in a MITM attack against Google users in Iran and as intermediate CA certificates wrongly issued by TurkTrust. These lapses in the CA infrastructure are sabotaging the confidence in the CA hierarchy of trust. This is the main reason why important browsers are embracing certificate pinning. Besides, public key pinning is supported by Firefox and Google Chrome, Microsoft is also considering it for inclusion in Internet Explorer and a new Web browser, Spartan.

Firefox and Chrome involve a built-in pinset – a list of certificates that are acceptable for big, high security websites – but as of now, no browsers are supporting dynamic pinsets. This means that the list of agreeable certificate authorities for every pinned domain has to be re-loaded at the time of application build-in. This brings in scalability issues and removes all but the major websites. With the help of website application security services, Both vendors try and look at how well dynamic pinsets have to be supported. Web administrators who want to prepare their websites for dynamic pinning have to return the Public Key Pins HTTP header, if their site is accessed over HTTPS. For example, the following header can be send through a web server, which tells the browsers to join a specific SSL certificate with a website.

Header set Public-Key-Pins "pin-sha256=\"base64+info1==\"; pin-sha256=\"backup+pin+here==\"; max-age=15768000; includeSubDomains" (Note: This requires enabling of apache mod_headers)

Including a pin for a backup certificate, which is not being used in production, is also a good practice. This assures that the site is accessible, even after the main certificate gets removed.

No comments:

Post a Comment