3 ms·

I always just use http://example.com http://example.com since it's managed by ICANN and if it ends up pwned then we have bigger problems. I don't know who is be

I always just use http://example.com http://example.com since it's managed by ICANN and if it ends up pwned then we have bigger problems. I don't know who is behind this one, or whether it will stick around or be sold off later. Example.com is (basically) forever.

talkmctalkface 7y ago
The owner of the website is here: https://twitter.com/colmmacc https://twitter.com/colmmacc
FDSGSG 7y ago
> if it ends up pwned then we have bigger problems Like what?
- roywiggins 7y ago
  Every single script that relies on example.com returning something sane and not malicious- I don't expect it to cause any disasters, but who knows?
hannob 7y ago
I used example.com in the past, though at some point I was looking whether there's any commitment from them never to default to HTTPS or use HSTS. Haven't found any. So I found it better to use some domain dedicated exactly for this (and I hope even if the person running neverssl.com chooses to stop doing so someone will probably take over).
deleted 7y ago
[deleted]
sowbug 7y ago
I'm being hyper-pedantic here. Wouldn't the relevant kind of pwning happen to you rather than to the site? I'm thinking something like a MITM at your local coffee shop's wifi or an evil employee at your work. If someone took over the machine serving example.com, HTTPS wouldn't have stopped it or helped alert anyone to it.
- roywiggins 7y ago
  The point is to generate a 302 redirect, so I guess it doesn't matter what example.com is actually serving if you never see it. But the captive portal may forward you along to it after you authenticate. This doesn't do anything to prevent a MITM at all, just that if neverssl.com starts serving crap you have a nonzero chance of loading it when trying to use it to generate a redirect. If there's a local MITM you're in trouble either way.
  - sowbug 7y ago
    That makes sense. My one change to the workflow is that I tend to visit example.com again, one last time, after jumping through the captive-portal hoops to make sure it's all really working. Thus I do see the content.

talkmctalkface 7y ago

The owner of the website is here: https://twitter.com/colmmacc https://twitter.com/colmmacc

FDSGSG 7y ago

> if it ends up pwned then we have bigger problems Like what?

roywiggins 7y ago
Every single script that relies on example.com returning something sane and not malicious- I don't expect it to cause any disasters, but who knows?

hannob 7y ago

I used example.com in the past, though at some point I was looking whether there's any commitment from them never to default to HTTPS or use HSTS. Haven't found any. So I found it better to use some domain dedicated exactly for this (and I hope even if the person running neverssl.com chooses to stop doing so someone will probably take over).

deleted 7y ago

[deleted]

sowbug 7y ago

I'm being hyper-pedantic here. Wouldn't the relevant kind of pwning happen to you rather than to the site? I'm thinking something like a MITM at your local coffee shop's wifi or an evil employee at your work. If someone took over the machine serving example.com, HTTPS wouldn't have stopped it or helped alert anyone to it.

roywiggins 7y ago
The point is to generate a 302 redirect, so I guess it doesn't matter what example.com is actually serving if you never see it. But the captive portal may forward you along to it after you authenticate. This doesn't do anything to prevent a MITM at all, just that if neverssl.com starts serving crap you have a nonzero chance of loading it when trying to use it to generate a redirect. If there's a local MITM you're in trouble either way.
- sowbug 7y ago
  That makes sense. My one change to the workflow is that I tend to visit example.com again, one last time, after jumping through the captive-portal hoops to make sure it's all really working. Thus I do see the content.