This is extremely exciting. I've been supporting these folks since the beta. It's great for offering free SSL to clients.
Progress Towards 100% HTTPS, June 2016
41–50 of 109 posts
Re: Progress Towards 100% HTTPS, June 2016
#42I'm still bitter about this chain of trust model. The fact that I have to get some other party to tell my users that they can trust me just seems wrong. They trust me because of personal history, not because some banner says they should. Browsers and OS vendors shipping CAs seems to be the root of the problem, in my mind. Those should be distributed by the service providers, who are the actual trustworthy entities in…
This isn't about trusting you, it's about trusting that your domain belongs to the IP address it's supposed to.
Re: Progress Towards 100% HTTPS, June 2016
#43Is it still problematic to issue lots of certs for lots of subdomains? I mean, still no wildcard certs and crazy rate limits, that disallow issuing 1000s of certs per day for user-generated subdomains?
Though if you are a hosting provider for example, I'm sure you could try to negotiate a deal with let's encrypt for more tolerant rate limits for a bit of sponsoring.
We do, in limited cases for large providers (we can only handle so many requests), adjust rate limits. Such adjustments are never dependent on sponsorship, though sponsorship is nice.
Re: Progress Towards 100% HTTPS, June 2016
#44Earlier quoted context omitted.
And when we visit your site for the first time, having never heard of you before, why should we trust you? That's the point. Having some authority who did at least some minimal checking, to extensive checking, and who will verify you really are who you purport to be. Trust but verify probably plays a part in this. But, remember, you don't have to go to HTTPS. There is no requirement for you to do so.
Why should you trust me if you have never met me? If you like what I do, trust me, and please give me money. :) Cert companies only do a phone call check for the very expensive EV certs. There is no minimal to extensive checking. That is a scam. Web tech is all https now. I can't even browse a lot of https sites with some of my older devices. There is a requirement and I dislike it.
>There is no minimal to extensive checking. That is a scam.
You generally have to modify the root domain to host a random value in a text file the cert company gives you. This demonstrates that you have control of the domain.
Aka, minimal checking.
Granted, that doesn't prove that you're the domain owner, but if you aren't the domain owner and you've got enough access to pass that challenge, the real own has security problems a cert isn't going to fix so hey.
All things considered, it's a hell of a lot better than nothing.
Re: Progress Towards 100% HTTPS, June 2016
#45Earlier quoted context omitted.
And when we visit your site for the first time, having never heard of you before, why should we trust you? That's the point. Having some authority who did at least some minimal checking, to extensive checking, and who will verify you really are who you purport to be. Trust but verify probably plays a part in this. But, remember, you don't have to go to HTTPS. There is no requirement for you to do so.
Why should you trust me if you have never met me? If you like what I do, trust me, and please give me money. :) Cert companies only do a phone call check for the very expensive EV certs. There is no minimal to extensive checking. That is a scam. Web tech is all https now. I can't even browse a lot of https sites with some of my older devices. There is a requirement and I dislike it.
> I can't even browse a lot of https sites with some of my older devices.
What devices do you have that don't support TLS?
Also, the point is not to trust you or not, it's to trust that I'm actually talking to you and not a MitM.
Re: Progress Towards 100% HTTPS, June 2016
#46Earlier quoted context omitted.
It would certainly be considered fraudulent by all major browser vendors, possibly leading to a death sentence for the CA (i.e. root removal) in cases of deliberate misissuance or massive negligence. Key pinning mechanisms and Certificate Transparency would make it quite likely that this kind of misissuance would be detected as well. My personal opinion on the "nation-state adversary forces CA to misissue" topic boil…
How would it be identified as anything other than a routine cert rotation? You would have to have proof that you were being served different certs for the same endpoint from different devices or locations, AND find someone who cares and is not under some influence. That sounds difficult for you, but easy for a central entity to detect. Ads follow me around between devices and locations, so I am quite sure a certifica…
If a site uses key pinning (e.g. via HPKP), the site is in control of telling you which keys are acceptable, so there would be no way to pretend it's a routine rotation after your first site visit (unless the site is cooperating, in which case you're screwed anyway).
Certificate Transparency would also help here, as it would allow site owners to monitor the logs for any certificates they did not request. This is more about detection as opposed to prevention (though the chilling effect of easier detection would help with prevention, I suppose). Admittedly, this is probably something only a couple of large, security-conscious organizations do (like, for example, Facebook, which detected that someone was issuing certificates against internal policy, though not maliciously in that case).
Re: Progress Towards 100% HTTPS, June 2016
#47Earlier quoted context omitted.
Why should you trust me if you have never met me? If you like what I do, trust me, and please give me money. :) Cert companies only do a phone call check for the very expensive EV certs. There is no minimal to extensive checking. That is a scam. Web tech is all https now. I can't even browse a lot of https sites with some of my older devices. There is a requirement and I dislike it.
> Why should you trust me if you have never met me? If you like what I do, trust me, and please give me money. What if a customer who trusts you returns to your site, but ends up on an impostor's site instead? He was no way to discern the difference.
I would argue strongly that such users do not have those abilities even with https. A valid cert is a valid cert. My supporting point would be the major browser vendors recent backpedal on throwing mixed-content errors, demonstrating that a smooth ride for the user is far more important than safety to them.
Actually I called shutterfly.com on the phone about that mixed content issue. I emailed them screenshots of the error from 6 different operating system and browser combinations, from 3 other users even. They claimed nothing was wrong. They were serving javascript via http on an https page and told me I was wrong and needed to update java, for weeks, on the phone, in chat, and in email, and declined to send the report to their webmaster. Even those wanting to be trusted are incapable of using these tools, from what I have seen. The whole thing is broken.
Re: Progress Towards 100% HTTPS, June 2016
#48I'm still bitter about this chain of trust model. The fact that I have to get some other party to tell my users that they can trust me just seems wrong. They trust me because of personal history, not because some banner says they should. Browsers and OS vendors shipping CAs seems to be the root of the problem, in my mind. Those should be distributed by the service providers, who are the actual trustworthy entities in…
This isn't about trusting you, it's about trusting that your domain belongs to the IP address it's supposed to.
IP addresses are not in certificates. Only hostnames. Not a rule, but I've set up hundreds and seen thousands, and never seen a single purchased cert that contained an IP.
Re: Progress Towards 100% HTTPS, June 2016
#49Earlier quoted context omitted.
For local traffic, why do you need a public certificate authority?
Because some devices and browsers have difficulty determining if they're talking to something on the local network or not. And they don't try to guess. So if your router requires you to connect via HTTPS, which is a good idea, have fun clicking past a nasty warning and then have nasty icons everywhere telling you that you're not secure. And before you tell me to set up my own local authority and add it to the chain o…
That's not a problem of browsers having a difficulty determining if they're talking to something on a local network or not, just because you're in a local network doesn't means you can't be victim of a MiTM.
Re: Progress Towards 100% HTTPS, June 2016
#50Blackberry 10 browser refuses to recognize Lets Encrypt certs :(