Don't Take Security Advice from SEO Experts or Psychics(troyhunt.com)
troyhunt.com
Don't Take Security Advice from SEO Experts or Psychics
https://www.troyhunt.com/dont-take-security-advice-from-seo-experts-or-psychics-neil-patel/
133 comments
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.
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.
> 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.
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.
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.
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
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?
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.
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.
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 [[email protected]:22222]:path/torepo.git, which is accepted by bash but people insist on zsh and other shells which break on the brackets)...
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)...
Why not use the URL syntax? Then you can do
Alternatively, each user could put into their ~/.ssh/config:
(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.)
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.)
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:
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
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.
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).
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
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?
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.
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.
"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.
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
[1] https://youtu.be/hkDD03yeLnU
I laughed so hard at this, almost peed myself.
Are you referring to The Band - The Weight? If so, then it is a fine song.
It would make more sense that way.
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?
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?
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.)
(See Ajedi32's response below.)
I'm not sure what that quote means. Can you explain it?
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...
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!)
I appreciate the save!
(Not being sarcastic!)
I think he's joking
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.
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.
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.
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.
> 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.
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."
The redirection of https to http on neilpatel.com is amazing. That's something I've never seen in my life.
Really? Another popular example is https://store.steampowered.com/.
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...
Yeah...you could just replace the HTTP landing page with your own containing your own login form.
Holy crap, I've never noticed that.
They 2FA me on every login and then do that?!
They 2FA me on every login and then do that?!
I've always used the app :/ that's disappointing.
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.
Ex:
https://twitter.com/searchmartin/status/895679103101091840
"The only thing @troyhunt gets wrong is thinking Neil is an SEO, not just a (talented) mouthpiece."
"The only thing @troyhunt gets wrong is thinking Neil is an SEO, not just a (talented) mouthpiece."
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.
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.
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.
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.
This is the reason I finally added SSL to my academic webpage.
> so I have some way to pop up the login page from captive wifi portals, I'm fine with everyone else going SSL
Isn't this the fault of those deploying the captive portal for not implementing RFC7710 and advertising a secure login URL?
Isn't this the fault of those deploying the captive portal for not implementing RFC7710 and advertising a secure login URL?
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.
> The threats (for example, somebody hijacks the request and returns different content) are minimal.
I wouldn't call injecting malware/adware/advertising minimal.
I wouldn't call injecting malware/adware/advertising minimal.
I use example.com for this purpose. I'm guessing that they'll keep listening on port 80 for quite some time.
I prefer example.org because I'm anti-capitalist and hate commerce.
I thought so too, but there was one US ISP that started injecting headers.
I had such a problem trying to figure out a site I knew that didn't use ssl yesterday for this! Thanks for the tip.
Your users might care when malware is injected into your page.
You can use example.com as well.
[deleted]
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.
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.
I wrote my experience of moving my blog to https about it here: https://jjude.com/cost-of-https/
I wrote my experience of moving my blog to https about it here: https://jjude.com/cost-of-https/
That's incorrect. Prior to 2.0 yes, but since 2.0 https is allowed. see https://validator.w3.org/feed/docs/rss2.html in the Comments section.
RSS is a terrible format. You should use Atom feeds.
Made me think of http://n-gate.com/software/2017/07/12/0/
Woah, sounds like Internet's Gollum with just one more personality.
Ugh it's like anti vaxxers of the technology sector.
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
SEO isn't about doing the right thing, it's about looking like you are doing the right thing
Step 1 - Make outrageous claim
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)
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)
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.
https://thestartupchat.com/
http://neilpatel.com/blog/
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/
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?
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.
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.
I do agree he needs to change web designers, the advice is golden so you don't need the gaudy design elements.
>Don't Take Security Advice from SEO Experts or Psychics
Maybe the "Security" is redundant?
Maybe the "Security" is redundant?
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.
Note that unless you're using a wildcard certificate, all your subdomains are public when you use HTTPS thanks to Certificate Transparency.
Wildcard certificate would not help, that only refers to validity, not destination host.
Wildcards do help.
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.
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.
Couldn't you use a separate certificate for super-secret-subdomain.example.com?
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).
No: https://en.wikipedia.org/wiki/Certificate_Transparency
The TL;DR version: Every certificate goes into the log. *.example.com going into the log is no problem for hiding a particular subdomain.
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 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.
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.
I think you are missing what is going on.
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.
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.
To clarify, the situation is a publicly reachable subdomain which you do not want others to know about?
Has anyone else noticed the "Right to be forgotten message" in google (in europe) upon searching the guys name?
I always think "what did they do" as if they're a criminal when I see this. But, realistically they're probably as likely to be a victim!?!
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.
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.
Doesn't it happen for all names?
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.
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.
Have you ever heard of anyone serving different content on http vs https pages with the same URL?
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.
For what it's worth, my largely ignored website ranked for 3x as many terms in Google Webmaster after I switched to SSL
What does this mean for intranet sites? Will those need to be HTTPS from October as well?
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.
Enterprises have the luxury of installing their own certificates on managed workstations.
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 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.
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.
Sidenote: Which parses better: buzzfeed-esque, buzzfeedesque or buzzfedian?
Neil appears to be deleting any negative comments
I think he deleted his Facebook post. I got "the page you requested can't be displayed right now..." message when I clicked the link.
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.