yes, i know, but accoring to the blogpost below it should be no problem for newser browsers when using tls 1.2, but might e usefull to keep compatibility with very legacy clients, no?
disclaimer: i'm not a crypto-guru, the ciphers used are copypasta'd from https://www.ssllabs.com/projects/best-practices/.
from what i've learned with webservers it depends on implementation: cipher-suites, keep-alive, session-ticket-reusage etc. this pic shows the perfomance for a webserver w/ different cipher-suites: https://8ack.de/static/bimages/ssl_perftest_r1.jpg
speaking of webservers, if you use the usual performance-tweaks you wouldnt see a big performance-drawback from userperspective (YMMV)
>> Basically you're saying that I'm playing with fire with SSH because I trust a host on first view: everything not stamped by a third party is rogue.
Nope. I'm saying nothing of the sort. I'm saying that if you do not have an existing trust relationship then bootstrapping one over a public channel is asking for trouble. Third parties happen to form a part of the solution we use for https. It is a flawed model and it is rife with problems.
But it's better than not having it at all.
So yes, you are playing with fire if you trust an SSH host on first view. You will get protection against someone changing the signature later, but you have no protection against a malicious MITM player who is well resourced. Like, say a government that can insert themselves at various ISPs and do what they like with your traffic.
>> Trust is not a commodity to be exchanged by money!
It's up to you to decide what trust is. What it is not is blindly trusting that nobody out there is performing an MITM on your data.
The likelihood of any one user to be the target of a MITM is vanishingly small. Once that certificate has been accepted, they will be notified if it changes anyways.
Furthermore, the "trust relationship" between a user and a CA is based on nothing more than the CA's sayso. Do you personally trust every cert that your browser does? What about your OS? Trust that they'll never issue a cert they shouldn't? Trust that their operations are secure?
And finally, the self signed CA still protects against passive monitoring and eavesdropping, which I'd say is a much more clear and present threat.
The difference being that we know the first one is happening right now.
The average user will probably not be MITM'd. There simply are too many users and not enough attackers. Additionally, the attacker must hit the user during their first visit to the site or never.
MITM attack if trivial over wifi. And the Snowden files have shown that it is trivial for the NSA too. In fact it is routinely done by the middle-east dictatures to spy on their dissidents.
All certificates have the revocation problem. The revocation mechanisms have serious performance and reliability issues (e.g. what do you do if you can't contact the server?) which means that hardly anybody uses them and most people who do are doing it wrong.
Somewhat short lived certificates (two weeks?) solve most problems around online revocation. But on that timescale a self signed isn't terribly convenient, so you still need some kind of issuing authority / infrastructure.
It absolutely does protect you from MitM. Does it offer full proof protection? No. But it adds a barrier between you and being trivially hit with a MitM.
To use an analogy: One could make the statement that a kevlar vest doesn't protect you from bullets, then cite an example when a military grade round went through one and killed a cop. However this statement would be equally misleading to yours, as we all know a kevlar vest is better than nothing and that it will stop a typical street bullet (e.g. handgun round).
You lose 50% of the benefit of HTTPS then. It is 1/2 about encryption and 1/2 about interception/impersonation/MitM protection.
The only way to do a self signed cert while maintaining all of the benefits is to have the client install your root CA into their CA store. However for the user to do so they have to fully trust you and your security (since for all they know you could generate fake certificates for Microsoft, Google, Amazon, etc that would show up as legit for them (certificate pinning aside)).
I really REALLY dislike the current HTTPs/SSL/TLS system, the fact that money and hassle is a literal cost to security is a huge problem. However self-signed certificates aren't remotely a solution.
sure, there exists a project already with a local copy of included sites; it would be ease (i think) to modify this project to download and evaluate a current db-copy on browser-start
