A self-signed cert could be supported and effectively trust on first use like SSH and have the same trust model as a DV cert.
Hopefully needless to say, it's a bad idea to blindly connect to SSH hosts without verifying the fingerprint. (Of course, everyone just types in "yes" because they're lazy). You have absolutely no guarantee you're talking to your server.
Hostile wi-fi networks, firewalls, ISP's and regimes mess with plain HTTP all the time. A TOFU "trust model" would make that a commonplace reality for HTTPS as well.
For what it's worth, verifying SSH hosts should be much easier than it is. For example, every cloud provider should display the host fingerprint after creating a new instance.
SSH is "trust on first use" because the trust is typically established ahead of time by provisioning a username/password or a public/private key pair.
Along the same lines, I can use self-signed certs to encrypt the HTTPS connection to my own server, and feel confident because I can validate that it is really my cert and my server.
The same is not true of connecting to, say, twitter.com.
For passwords, it's obvious, because a malicious server can just save your username and password, but public keys are not immune either, as a bad actor can "pretend" to be your server and hope you enter an access key or something.
And you can even tie that to TLS: https://en.wikipedia.org/wiki/TLS-SRP
No, it can not. Self-signed certs, if not verified prior to first visit to a site or being trusted in case of company intranet sites, are vulnerable to a MITM attack - which is why browsers are warning if they can't detect a valid trust path.
Also, SSH is only secure on first use if you verify the fingerprints (and that is why ssh will ask you if you know/trust the hash on first connect).
Side question: does anyone know of a SSH "loadbalancer", working like HTTPS SNI so that multiple domains can have ssh on the same IP and port?
I think the term you're looking for is "bastion host" or "jump host". Basically you SSH into the bastion server and then run another SSH command to get to the destination server; newer versions of the SSH client apparently support a -J option to do this automatically.
Any TCP loadbalancer will do as long as all the hosts share the host key, which is considered bad practice but isn't worse than e.g. Sharing a TLS certificate, which is not considered a horrible practice.
More context: the server in question is running gitlab in a docker container, and users should also be able to SSH into the server. Now I have to run either gitlab or the host sshd on a different port, which confuses users and often enough leads to problems with git clone (the syntax is [[email protected]:22222]:path/torepo.git, which is accepted by bash but people insist on zsh and other shells which break on the brackets)...
git clone ssh://[email protected]:2222/path/torepo.git
Alternatively, each user could put into their ~/.ssh/config:
Host gitlab
Hostname gitlab.example.com
Port 2222
User git
(In this particular scenario a bastion host probably isn't useful, since you'd have to copy the SSH keys out of gitlab into the bastion and make sure you get the management/security right. A web search for "ssh forward git user" turns up a number of people struggling with your problem; none of them seem to have entirely satisfactory answers.)
The gist of it is that it looks like you probably have "git.my.tld:22222" set somewhere in your config file, which should be removed and replaced with:
gitlab_rails['gitlab_shell_ssh_port'] = 22222
yep, exactly. ssh normally does not need a portnumber if you are running gitlab-ssh on standard tcp/22.
I also wish that more browsers supported OpenPGP certificates instead, as it is a simpler while at the same time more powerful format (allows for multiple signatures for example).
There would be obvious problems with encouraging you as a user manage pinning (how would you know whether a site will deviate from what you pinned?) If you understand that but want to pin as a user anyway, chrome will let you do that: chrome://net-internals/#hsts
Aren't the hashes there only for the public keys of the site instead of the public key of the CA?
Also, does anybody happens to know any extension for Firefox that does anything similar to that?
"Some are on domain validation which is 2048+ BitSH42 SSL/TLS encryption the encryption key is limited which means you can use on a few pages and has a limited band weight"
What about THESE people? The ones on limited band weights that can only use a few pages?
This is a 100% valid complaint about 2048+ BitSH42 protocols that I've had for some time and no-one ever acknowledges it or suggests a solution.
It's funny because that's an actual quote from Maria Johnsen's article ["Should multilingual websites use HTTPS by default"][1], and the fact that she actually wrote that in a supposedly serious article discussing the merits of HTTPS makes it pretty clear she has no idea what she's talking about when it comes to security. (Especially compared to "this Troy Hunt guy", who is a well-known expert in the information security industry.)
[1]: https://web.archive.org/web/20160621124800/https://www.maria...
I appreciate the save!
(Not being sarcastic!)
(See Ajedi32's response below.)
On a side note, I'm glad at least one other person listens to The Band. Rock and roll is not dead!
(Or it is, if Lester Bangs in Almost Famous is to be believed).
I've gone well off the thread and into the wilderness here haven't I?
So no, not HTTPS is a threat, but company's unwillingness to innovate. So Chrome's and Firefox's public shaming of unsafe websites is really doing everyone a service.
The best thing I've ever done to serving HTTPS was to use Caddy with Let's Encrypt. Seriously. It was incredibly easy to set up. And I've never used Caddy before. https://caddyserver.com/docs/automatic-https describes how to have TLS available right from the first request served.