| > - It's somewhat complicated for a site to implement correctly This is true, but the same thing was said about running a site at all not long ago. > - It mainly protects users who have already connected to a site once from a secure location and whose browsers support HSTS and other "fixes" The point of using a valid CA is to allow the first connection be secure. It's certainly true that you can secure subsequent connections more than the initial one though. > - Circumvented easily via phishing Phishing is attacking something completely different and is not something SSL/TLS can or should protect you against. It's like expecting a seat belt to protect you from being run over. > - Does not prevent nation states from MITMing connection Actually it does if HPKP is used, though not on the initial connection. > - Can only host one site per IP, without a wild-card or UCC cert (which not all clients support) This is supported via the server name indication extension, and additionally by using multiple subject alternative names. The former is better though since it allows each site to have its own key. > - Makes caching difficult to impossible True, but that's a feature. Caching on the client is still of course entirely based on what the client chooses to do. > - Adds performance overhead Not much, see https://istlsfastyet.com/ > - Potential for new attacks on the TLS layer (SSL Strip, STARTTLS Command Injection, BEAST, POODLE, RC4, CRIME, TIME, BREACH, Truncation, FREAK, Logjam, Heartbleed, BERserk, Root cert forgery, ChangeCipherSpec injection, Protocol downgrade, Certificate errors, Renegotiation, Triple Handshake, Virtual Host confusion, DoS) Note that there are protections again those, and saying "because it might have a problem" is basically just burying your head in the sand of the problem you already have. > - General confusion by users as to what makes a connection secure True, but not a good reason since you as a site owner can do most of the work for them (in combination with their browser). |