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.
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.
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.
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.
> 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)...
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).
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
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.
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. I agree with this criticism of Neil Patel, and the things written about why SSL matters.
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.
Lol they're HTTPS on the login form but plain HTTP immediately after... what a joke? That invites people to do cred fishing on bigger LAN parties or conferences...
It took me a minute of browsing around the site and then coming back here to ask, before I realized that you're saying they're redirecting httpS to PLAIN http. Wow.
I've actually seen it a few times myself but I don't have any examples offhand. My company's filter is lazy so it doesn't filter https traffic. Sometimes if I get a blocked site that's http I try the URL with https instead. Once in a while I get a redirect to http.
> JFC, people, stop linking to his site. Links are currency
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.
I like what Brian Krebs does. He doesn't link to any sites, he shows screenshots and says "this was posted by user paulgb on news[dot]ycombinator[dot]com."
If you want to avoid a warning, then yes. That said, is it such a bad thing for enterprises to ramp up the use of HTTPS in their internal networks? This can help prevent some MITM attacks from attackers to breach the perimeter.
Enterprises have the luxury of installing their own certificates on managed workstations.
It seems that if you plugged into an ethernet port at many companies you'd be able to grab a lot of valuable information due to the lack of HTTPS. The move to SaaS products by departments inadvertently protects the company data in this case while IT teams still rail cloud usage.
If other enterprises are similar to the one where I work, the warning will not come up in October. Like all software, we're a few versions back on Chrome. It'll take some time to get up to Chrome 58 :)
It doesn't seem like an unreasonable requirement. Multiple people might be on the same company network, but they might not all have the same capabilities. By using HTTPS you reduce the risk of credentials being leaked.
As long as neverssl.com still exists so I have some way to pop up the login page from captive wifi portals, I'm fine with everyone else going SSL.
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.
First time I hear of RFC7710, all I see is HTTP hijacking. Does anybody support it, in particular OS vendors? I suppose some new UI or a new API for browsers would be required.
There are ISPs that have tools to inject arbitrary code into HTTP webpages. For example, My ISP injects notification banners into my web browser sometimes.
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.
Minimal depending on location. In the USA, worst we have heard about is tracking cookies and injected notifications. In China, for example, malware injection has occurred from ISP's ad networks.
Without certificate pinning, I'm not sure that SSL everywhere is really going to help. Larger ISPs or corporate networks will just get pushed more into the arms of companies like Bluecoat that provide proxies to effectively man-in-the-middle SSL traffic.
Certificate pinning won't stop that either. Most browsers e.g. Chrome ignore pinning rules if the certificate is installed on the device by the user (or their employer).
I'm always happy to read Troy's writing and heed his advice. I'm not sure about the whole "Perhaps Neil Patel is hoping that people will be too distracted looking at him in his pyjamas to notice" thing though. I do feel one can offer counter arguments without resorting to that kind of insult and teasing. Especially when you are right.
SEO is a shady field in general, but not all of it is shady. It can make or break a company and is well worth understanding. There is a lot of bad information out there (like the HTTPS advice above), so it's difficult to find accurate information.
I do not understand what you are trying to say. The destination would still be under SNI.
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.
Apparently, the intended scenario would be a subdomain which is public accessible but the owner wishes to keep secret, so their concern is actually just the domain existing in CT logs (I am aware that it makes zero sense).
Whatever Troy says is true. But for bloggers, please know this. The RSS 2.0 spec specifies that the feed url must be http url (and not https). So if you want your feed url should validate (which is a requirement for certain aggregators like AllTop), then it has to be http.
Well a big thank you to Michael James Field in the comments section. I forced http -> https in cloudfront over the weekend and my traffic from google has been down 20% and falling since. I didn't realise google treated different protocols as different sites. Thank you.
Absolutely. Not sure how its handled by cloudfront, but make sure you 301 redirect from http to https. And if you monitor your traffic in Google's Search Console tool (why wouldn't you?), you have to set up the https version as a completely separate site. Data for the http site is not reflected in the data for the https site, and vice versa.
So if you add HTTPS to your site you lose continuity of stats and have to amalgamate statistics across "2" sites from then on? .. there's a really good reason for Google to do this, right?
Technically you can serve different content on http and https (same as with www and non-www). Search Console also allows a way to group together sites to view data/stats together.
I certainly have not considered a reason for doing that myself. I'm just saying that is the case and it is important to be aware of it to ensure you get credit for backlinks to your site and avoid duplicate content penalties.
Given that this guy seems to delete comments that show he's wrong, my first instinct was to assume that he was trying to silence detractors. That may be unfair on my part though.
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.
I kind of suspect that someone who has 909442 likes and 909143 people following him knows how to game the system .... And sadly while he may know little about security he may know how to pretend that people like him, which I guess is some form of SEO
FYI Neil Patel is the co-founder of both CrazyEgg and Kissmetrics. He blogs, has a popular podcast and gives away some pretty valuable marketing information for free. I follow him and have never thought that he was primarily an SEO expert. He speaks about startup marketing and SEO is certainly a big part of that.
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.
I dropped him off my regular rounds quite some time ago and am generally wary of clicking his site when it comes up in organic searches. I find his site incredibly annoying and very rarely is the information so unique that it couldn't be found elsewhere.
I stopped following Neil when one of his posts (written by one of his writers) plagiarized someone else's post and he was publicly called out on it.
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.
There are a lot of people advising startups on marketing that have never run a startup. Neil Patel has done it twice, once bootstrapping and the second time raising venture capital. Actually he's done it more times and has talked about his failures and what he's learned.
I do agree he needs to change web designers, the advice is golden so you don't need the gaudy design elements.
In a way that's even more damning, because he's not just an SEO or marketing guy, he's actually built a couple true tech startups. Presumably he wasn't involved in the security, but it's still extremely alarming that someone with that background would spread such blatant disinformation. Some of his misunderstandings are initially forgivable, but then to delete comments pointing out his mistakes, not issue any correction, and continue blasting out patently false information to a large following is the sort of willful ignorance that deserves to be called out very publicly, hopefully with severe damage to his reputation (although I'm not holding my breath). If he's silencing feedback from actual security experts then what is he whitewashing in other domains?
There is a reason those guys actively denounce SSL. They use snip.ly and other tools that hijack the clicks from their social media references with an overlay to promote their products. The users see the WSJ or NYT article they clicked on with a free ad for the person who shared it underneath (possibly data too). Those overlays don't work over SSL pages.
133 comments
[ 2.9 ms ] story [ 170 ms ] threadSo 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)...
Alternatively, each user could put into their ~/.ssh/config:
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:
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!)
[1] https://youtu.be/hkDD03yeLnU
> Expert
You have to pick one
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."
Enterprises have the luxury of installing their own certificates on managed workstations.
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.
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.
I wrote my experience of moving my blog to https about it here: https://jjude.com/cost-of-https/
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.
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.
https://thestartupchat.com/
http://neilpatel.com/blog/
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.
https://twitter.com/troyhunt/status/895800744787546114
https://twitter.com/troyhunt/status/895758193896202240
https://twitter.com/troyhunt/status/895757970729979904