Hacker News Reader

Comment by justusw | Hacker News Reader

I've noticed that a lot of the hostility towards HTTPS comes from those who do really shady things online. Like pop-under advertisers that are unhappy that they have to update their own infrastructure, otherwise their unsafe mixed content won't be loaded by a browser.

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.

View on HN

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.

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

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

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

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

You and this Troy Hunt guy have completely missed the central point that Maria is making.

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

Are you referring to The Band - The Weight? If so, then it is a fine song.

Were this reddit I'd invite you to take a load off, but that kind of behaviour invites (incites?) downvotes round here. So I shan't!

But apparently saying you'd get downvoted gets you downvoted just the same. Just like on Reddit!

You know what? It's fair. I'd downvote me for saying "hope I don't get downvoted" too.

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?

It would make more sense that way.

Google search shows "BitSH42" is mentioned only in this discussion.

This was tongue-in-cheek. My own fault for not being clearer.

(See Ajedi32's response below.)

I'm not sure what that quote means. Can you explain it?

I think he's joking

I guess I missed it because I can't even parse the quote.

None of us can

It means nothing. The whole quote is pure nonsensical technobabble; headmelted is joking by sarcastically bringing it up as a valid concern.

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

Sincerely, thank you. I was panicking for a moment there.

I appreciate the save!

(Not being sarcastic!)

The solution to this has been know for a while, its creating a GUI interface in Visual Basic to track the domain's IP address.[1]

[1] https://youtu.be/hkDD03yeLnU

I laughed so hard at this, almost peed myself.

I hope the packages for Apache in mainstream distros will include good defaults settings, I remember somehow hunting for the rules to redirect to https.

Reply on news.ycombinator.com