6 ms·

To me it felt rogue since it had been generated without me knowing nor expecting it, whereas I expect CloudFlare to do it. This is not an official feature of Gi

by suixo 8y ago

To me it felt rogue since it had been generated without me knowing nor expecting it, whereas I expect CloudFlare to do it. This is not an official feature of GitHub... But I understand the word may be too strong. For CAA I would love to, but my registrar still doesn't allow me to create these kind of records :/

regecks 8y ago
Cloudflare is interesting because they do it even if you don't and have never used their proxy service, just their DNS hosting. I was surprised when they issued certificates for my domains (as well as injecting a tonne of broad CAA records into my zone). You have to disable Universal SSL from the bottom of the Crypto tab. So, on second thought, I sympathize with you.
- icebraining 8y ago
  Cloudflare is interesting because they do it even if you don't and have never used their proxy service, just their DNS hosting. Ah, so that's why they made one for HN. Thanks!
  - half-kh-hacker 8y ago
    Their DNS hosting != Their public DNS server, announced at the start of this month.
mo3gut 8y ago
> To me it felt rogue since it had been generated without me knowing nor expecting it That's understandable. Fastmail do the same, i.e. acquiring certs for their customers' domains without asking or informing, with a view to moving them to HTTPS. The general opinion here seems to be in favour of this practice. So we can look forward to a future where your domain may publish on the web only with the permission of a CA.
- tombrossman 8y ago
  > Fastmail do the same, i.e. acquiring certs for their customers' domains without asking or informing, with a view to moving them to HTTPS. Not sure about the the down-voters, but I was just about to post a 'citation needed' comment dismissing this as crazy talk, and I was surprised to discover it is actually true: https://www.fastmail.com/help/files/secure-website.html https://www.fastmail.com/help/files/secure-website.html
jerf 8y ago
I've banged on this before in HN, but SSL certificates do not mean what many (if not most) people here seem to think they do. They do not mean that you are communicating directly with a person, or even that some person approved the communication, or the same for a company. It may sound silly when I say it, because obviously we aren't actually getting webpages from a person, but it's important to internalize. They mean something much more like "you are communicating with a machine authorized to respond on this domain by the owner of that domain". There is no obligation that the machine in question belongs to the domain owner. So when you delegated the (sub-)domain to GitHub, you also delegated the ability to generate at least low-class SSL certs to verify that delegation is correct and authorized and that HTTPS is legal. What's important is that nobody can get that authorization without your delegation. And even with Let's Encrypt, you should find you can't just stroll out and get a certificate for any domain you choose. At some point you have to have control of the domain itself to get a cert. (This is also why I have no problem with anything Cloudflare does with a certificate. There is no reason that they can't be shared with an authorized delegate by the domain owner. What matters is that CloudFlare can't do it without authorization, and if the owner wishes to revoke that delegation they have a clear path and CloudFlare can't do anything about it.[1] Cert delegation happens all the time, though; everyone running their HTTPS website off a hosted VM image is delegating the actual HTTPS-ing to the VM host, for instance.) The tricky bit here is that you did not fully understand what you were authorizing when you delegated the domain to GitHub. No criticism intended, this is complicated business. It somehow needs to be fixed but heck if I know how. [1]: In this case, note that CloudFlare may have a valid cert for your domain for a while after you leave, but when people check DNS to find where your domain is, they'll connect to you rather than CloudFlare. This is not a CloudFlare-specific issue, it would apply to GitHub here or any other delegate. The fundamental gap here is that domain delegation has no temporal component and SSL certificates do; an impedance mismatch is inevitable. In theory you ought to be able to revoke their certificate but that's a shipping container loaded with cans of worms.
- axaxs 8y ago
  Great explanation. As someone getting into automated customer ssl cert setup, i've found a lot of people have this misconception that it's some super secret sacred identity, when really it's more about machine to machine trust imho.
patcheudor 8y ago
Nothing is rogue when you point your DNS to someone else's host. Because you pointed a domain you owned at GitHub, it was then possible for GitHub to obtain a certificate for your domain. Sure, maybe something was missed in the terms of use, but this is something everyone needs to understand. Pointing your domain at someone else's server allows them to get a certificate for that domain. That's how domain validated (DV) certs work, it's how they've always worked.
web007 8y ago
CAA wouldn't help in most cases! If you have an IP based delegation (A or AAAA record) you're probably okay, but if you have CNAME delegation you're beholden to the named entity. I've commented on this before on HN when CloudFlare did the same thing to me: https://news.ycombinator.com/item?id=16579486 https://news.ycombinator.com/item?id=16579486
Boulth 8y ago
When I started using CloudFlare for DNS only, without any of their extras, they also did generate cert for my domain and it's impossible to disable this behavior through UI (requires contact with support). I did not expect that because I just wanted DNS, no traffic through them and I got a cert with my domain intermixed with some strangers.

by suixo 8y ago

regecks 8y ago

Cloudflare is interesting because they do it even if you don't and have never used their proxy service, just their DNS hosting. I was surprised when they issued certificates for my domains (as well as injecting a tonne of broad CAA records into my zone). You have to disable Universal SSL from the bottom of the Crypto tab. So, on second thought, I sympathize with you.

icebraining 8y ago
Cloudflare is interesting because they do it even if you don't and have never used their proxy service, just their DNS hosting. Ah, so that's why they made one for HN. Thanks!
- half-kh-hacker 8y ago
  Their DNS hosting != Their public DNS server, announced at the start of this month.

mo3gut 8y ago

> To me it felt rogue since it had been generated without me knowing nor expecting it That's understandable. Fastmail do the same, i.e. acquiring certs for their customers' domains without asking or informing, with a view to moving them to HTTPS. The general opinion here seems to be in favour of this practice. So we can look forward to a future where your domain may publish on the web only with the permission of a CA.

tombrossman 8y ago
> Fastmail do the same, i.e. acquiring certs for their customers' domains without asking or informing, with a view to moving them to HTTPS. Not sure about the the down-voters, but I was just about to post a 'citation needed' comment dismissing this as crazy talk, and I was surprised to discover it is actually true: https://www.fastmail.com/help/files/secure-website.html https://www.fastmail.com/help/files/secure-website.html

jerf 8y ago

I've banged on this before in HN, but SSL certificates do not mean what many (if not most) people here seem to think they do. They do not mean that you are communicating directly with a person, or even that some person approved the communication, or the same for a company. It may sound silly when I say it, because obviously we aren't actually getting webpages from a person, but it's important to internalize. They mean something much more like "you are communicating with a machine authorized to respond on this domain by the owner of that domain". There is no obligation that the machine in question belongs to the domain owner. So when you delegated the (sub-)domain to GitHub, you also delegated the ability to generate at least low-class SSL certs to verify that delegation is correct and authorized and that HTTPS is legal. What's important is that nobody can get that authorization without your delegation. And even with Let's Encrypt, you should find you can't just stroll out and get a certificate for any domain you choose. At some point you have to have control of the domain itself to get a cert. (This is also why I have no problem with anything Cloudflare does with a certificate. There is no reason that they can't be shared with an authorized delegate by the domain owner. What matters is that CloudFlare can't do it without authorization, and if the owner wishes to revoke that delegation they have a clear path and CloudFlare can't do anything about it.[1] Cert delegation happens all the time, though; everyone running their HTTPS website off a hosted VM image is delegating the actual HTTPS-ing to the VM host, for instance.) The tricky bit here is that you did not fully understand what you were authorizing when you delegated the domain to GitHub. No criticism intended, this is complicated business. It somehow needs to be fixed but heck if I know how. [1]: In this case, note that CloudFlare may have a valid cert for your domain for a while after you leave, but when people check DNS to find where your domain is, they'll connect to you rather than CloudFlare. This is not a CloudFlare-specific issue, it would apply to GitHub here or any other delegate. The fundamental gap here is that domain delegation has no temporal component and SSL certificates do; an impedance mismatch is inevitable. In theory you ought to be able to revoke their certificate but that's a shipping container loaded with cans of worms.

axaxs 8y ago
Great explanation. As someone getting into automated customer ssl cert setup, i've found a lot of people have this misconception that it's some super secret sacred identity, when really it's more about machine to machine trust imho.

patcheudor 8y ago

Nothing is rogue when you point your DNS to someone else's host. Because you pointed a domain you owned at GitHub, it was then possible for GitHub to obtain a certificate for your domain. Sure, maybe something was missed in the terms of use, but this is something everyone needs to understand. Pointing your domain at someone else's server allows them to get a certificate for that domain. That's how domain validated (DV) certs work, it's how they've always worked.

web007 8y ago

CAA wouldn't help in most cases! If you have an IP based delegation (A or AAAA record) you're probably okay, but if you have CNAME delegation you're beholden to the named entity. I've commented on this before on HN when CloudFlare did the same thing to me: https://news.ycombinator.com/item?id=16579486 https://news.ycombinator.com/item?id=16579486

Boulth 8y ago

When I started using CloudFlare for DNS only, without any of their extras, they also did generate cert for my domain and it's impossible to disable this behavior through UI (requires contact with support). I did not expect that because I just wanted DNS, no traffic through them and I got a cert with my domain intermixed with some strangers.