Don't Take Security Advice from SEO Experts or Psychics
troyhunt.com
troyhunt.com
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.
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.
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 [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)...
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.)
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.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?
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.
"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.
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?
(See Ajedi32's response below.)
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!)
2. Neil Patel does not speak for all SEOs :) ...I've read several comments from other SEOs who strongly disagree with what he said.
3. JFC, people, stop linking to his site. Links are currency--it does not matter to him, big picture, if the link is framed by a sentence that says "this person is an idiot." Links only help increase his authority and ability to reach new people.
They 2FA me on every login and then do that?!
Hear, hear! This applies to just about everything people get outraged about these days: making people outraged on the internet is a business model that works. If you don't like that, ignore the things that outrage you instead of taking the bait.
"The only thing @troyhunt gets wrong is thinking Neil is an SEO, not just a (talented) mouthpiece."
However, I basically agree that if you're just hosting a blog with no user interaction, there's really no need for it. The threats (for example, somebody hijacks the request and returns different content) are minimal.
I wouldn't call injecting malware/adware/advertising minimal.
Isn't this the fault of those deploying the captive portal for not implementing RFC7710 and advertising a secure login URL?
Even if the ISP means well at the beginning, the tool can be abused (ISPs injecting tracking, or reading the tracking information so they can sell it). Attackers at coffee shops and conferences can do much worse.
I wrote my experience of moving my blog to https about it here: https://jjude.com/cost-of-https/
Step 2 - Receive lots of inbound links from people upset with your outrageous claim
Step 3 - Cash in on your increased audience (or become elected President)
He does preach that unless you have the capital, blogging and SEO are one of your few alternatives for marketing in the beginning of your startups life. He may very well be wrong on SSL but surprised he doesn't have other fans on here. I personally have learned a lot from the guy.
Neil has been around for a long time... I remember him from the old SEO conference days (PubCon), and at that time he was putting out good material. He's turned into a content marketing organization, the majority of content written by people who he hires to write in his name.
I do agree he needs to change web designers, the advice is golden so you don't need the gaudy design elements.
Maybe the "Security" is redundant?
If you've got super-secret-subdomain.example.com, a wildcard for *.example.com doesn't expose its existence. A non-wildcard certificate does.
There's a bit of security-via-obscurity going on here, but sometimes the need for such a thing is out of one's control.
Exposing existence is a separate matter, the only thing I can think of is that you're referring to those TLS certificates with multiple domains (almost just as bad as a wildcard certificate). Now that TLS certificates are free, each subdomain can indeed have its own certificate, thereby not causing any exposure.
Lets say you have super secret domain xsrihghufgyssw.foo.com, it is published in your DNS and it is publically reachable, but no one ever knows to look up that domain to reach the website. It is almost impossible for someone to randomly stumble upon or guess that domain name. With certificate transparency there is a log of that certificate being registered so if some group like DDOS for hire wanted to take your services out, they could use all those names as targets.
The TL;DR version: Every certificate goes into the log. *.example.com going into the log is no problem for hiding a particular subdomain.
On a more general point, does anyone know how to find what pages that are delisted are? I seem to remember some newspaper publishing the pages of theirs that had been delisted.
Enterprises have the luxury of installing their own certificates on managed workstations.