Hacker News Reader

Comment by Spivak | Hacker News Reader

The other hostility being that HTTPS bundles encryption with identity verification. The fact that we've bundled the practical ability to encrypt your site with a 3rd party gatekeepers is really off-putting to people.

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.

View on HN

> A self-signed cert could be supported and effectively trust on first use like SSH

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.

I don't know how you use SSH, but I don't permit or establish anonymous SSH connections the way I do anonymous HTTPS connections.

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.

You are right in that SSH is TOFU because trust can be established beforehand, but you cannot establish trust based on whether or not a password or public key is accepted. You need to establish trust separately (with the server's public key), usually before you ever authenticate.

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.

Actually, you can, and just using passwords! Using a PAKE protocol, the client and the server can prove to each other that they know a certain password, without revealing it.

And you can even tie that to TLS: https://en.wikipedia.org/wiki/TLS-SRP

Yes, but SRP for SSH isn't specified or implemented into any SSH implementation that I know of. My comment was about SSH today, as apparently the GP is currently using this as a method to authenticate servers.

Ah, fair enough. As a matter of curiosity, OpenSSH did start an implementation of J-PAKE, but it was abandoned before ever becoming stable :|

> 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.

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?

> 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.

But that's not loadbalancing - you still have to trust any host you get to through the jump host; with a new enough ssh and sshd, you can use a CA to sign host or client keys, and get an experience similar to https. (There is even a DNS record for that, iirc)

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.

They weren't looking for load balancing in the "keep it even between identical hosts" sense, but rather in the manner that you might use a "load balancer" appliance to look at the SNI and direct the request to the correct machine for the given hostname. (See our conversation elsewhere on the thread for why they wanted to do this.)

The SNI thing breaks down, because an SNI redirector (which is what GGP is after - not load balancer) strips the SSL and continues in plain http beyond; I think you have to specially compile sshd these days if you want it to accept plaintext connections, and it is highly discouraged (for very good reasons).

Thanks for -J, that helps a bit but is not what I want to avoid :(

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 [git@git.my.tld:22222]:path/torepo.git, which is accepted by bash but people insist on zsh and other shells which break on the brackets)...

Why not use the URL syntax? Then you can do

    git clone ssh://git@gitlab.example.com:2222/path/torepo.git

which shouldn't be mangled by the shell. (In fact, this is the syntax that GitLab gives you by default.)

Alternatively, each user could put into their ~/.ssh/config:

    Host gitlab
        Hostname gitlab.example.com
	Port 2222
        User git

and then use "gitlab:path/torepo.git" instead.

(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.)

Because gitlab does not provide this syntax (if you do know how to get it that way, please tell me!), and people like to copy-paste... and getting people to set up their .ssh/config, tried that and failed, I would not ask if that were an option :(

My GitLab CE instance (also docker) provides the URL syntax, so I did some spelunking through GitLab's source to figure out what might be different with your instance and found build_gitlab_shell_ssh_path_prefix: https://gitlab.com/gitlab-org/gitlab-ce/blob/c946ee1282655d3...

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

Alternatively, you may have gitlab_shell['ssh_path_prefix'] set which would cause the same symptoms.

I have never had to use the brakets like that when referring to a remote path in shell (bash or zsh). Is it because of the port number? Perhaps I never used a port number in the string, but im pretty sure I've needed it at some point (jenkins ran on :8080).

> Is it because of the port number?

yep, exactly. ssh normally does not need a portnumber if you are running gitlab-ssh on standard tcp/22.

I was not aware of -J, thanks for the comment :)

I wish that modern browsers made it possible to trust a CA certificate only for specific sites, or to pin the one used in a specific site so other CAs can't be used silently.

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).

HSTS already protects you from attackers that get another CA to sign their certificate.

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

>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?

I think that's HPKP you're thinking of; HSTS only declares that the site plans to continue requiring HTTPS without specifying a CA or public key that it will use.

Reply on news.ycombinator.com