Most underwhelming product launch ever.
Search.chatgpt.com domain and SSL cert have been created
71–80 of 126 posts
Re: Search.chatgpt.com domain and SSL cert have been created
#72Earlier quoted context omitted.
Let’s encrypt and similar ACME compliant services allow you to get wildcard certs through their DNS-01 challenge.
A wildcard cert is an unnecessary risk, though. Just because I trust a server to hold the cert for preview.example.com doesn’t mean I’d want it to be able to pose as prod.example.com, for example.
As with most things, it's a tradeoff of security vs convenience/usability. The CIA Triad comes to mind. I advocate for using separate domains for dev, staging, and prod (at least prod vs. non-prod) and for a wildcard cert for a non-prod domain, the convenience far outweighs the security risk IMHO.
But yeah generally speaking, it's best to avoid wildcards unless there's an actual benefit to using them, even when it's not a prod domain.
Re: Search.chatgpt.com domain and SSL cert have been created
#73Re: Search.chatgpt.com domain and SSL cert have been created
#74I'm taking this opportunity to once again ask for the widespread adoption of the Name Constraints extension in x509, and subsequent roll-out of constrained intermediate CA certs signed by a publicly trusted root. Would be so convenient to have an intermediate CA cert constrained to *.my-name.com to avoid situations like this. Being forced to either use a private PKI infrastructure or using wildcards to not leak host…
You can just buy a regular wildcard certificate for *.my-name.com If your organisation is competent enough to handle an intermediate CA certificate safely, you're certainly competent to handle a wildcard cert safely which is a much easier task. Sadly it's unlikely you'll ever see the Name Constraints extension adopted. All it takes is one model of 15 year old smart TV failing to respect it, and the CA/Browser Forum w…
While I principally agree, the neat thing with the intermediate CA is that it can be centralised and support ACME, which makes maintaining the certs so much easier.
In my current org we have hundreds of TLS termination "configuration points" (cdn's & cloud loadbalancers / networking appliances / k8s ingress controllers / raw VM's). We have standardised on ACME issued certs for almost everything. Using a wildcard certificate would force us back to manual cert updating procedures, or finicky scripts. Undoubtedly causing issues when certs become expired.
(Not to mention the trust boundaries. An org can be competent enough to handle an in-house CA securely, and simultaneously have a bunch of quasi-sloppy vendors for stuff like the visitor badge kiosk.)
But I sadly agree that it will probably never happen…
Re: Search.chatgpt.com domain and SSL cert have been created
#75It's a clever way of getting around the accusations of stealing content. They can say that they are scraping it to make it searchable, just like Google.
It will be interesting to see what happens to copyright claims against ChatGPT. Google can just remove claimed content from its index, what will OpenAI do?
Use their legal and PR fund to fight back.
Re: Search.chatgpt.com domain and SSL cert have been created
#76Earlier quoted context omitted.
A wildcard cert is an unnecessary risk, though. Just because I trust a server to hold the cert for preview.example.com doesn’t mean I’d want it to be able to pose as prod.example.com, for example.
Why? As I understand it, the domain owner can assign the name you “trust” to any server already. Might as well trust all names by that domain owner.
Because if your one wildcard cert gets compromised somehow, the attacker can now impersonate every subdomain of yours. Consider what happens if there's an old test box called daves-test-box.example.com that has a copy of the wildcard cert valid for *.example.com. Dave quits and never updates his box. Eventually an unpatched CVE gets used to steal the cert. Now the attacker can phish or MitM your users of www.example.com using the stolen cert and browsers will trust it. If you'd instead of wilcard certs used specific ones, then the only thing the attacker can do with it is MitM or phish the users of Dave's test box, which is approximately zero.
There are certainly other strategies and best practices that can mitigate the risk in this scenario, but not using wildcards is a good one to include.
Re: Search.chatgpt.com domain and SSL cert have been created
#77[deleted]
Re: Search.chatgpt.com domain and SSL cert have been created
#78Earlier quoted context omitted.
A wildcard cert is an unnecessary risk, though. Just because I trust a server to hold the cert for preview.example.com doesn’t mean I’d want it to be able to pose as prod.example.com, for example.
A server allowed to hold preview.example.com (and its associated DNS records) cannot pass dns-01 for *.example.com. Unless you have no authz on your DNS configuration, in which case this server is allowed to hold prod.example.com since it can edit that record.
The main point of DNS-01 is that it doesn't have to be the same machine requesting the cert and using it. You can easily use DNS-01 from your laptop to get a cert for prod boxes. I have a script that runs as a k8s cron job that uses DNS-01 to renew all the certs and stick them in k8s secrets automatically.
Re: Search.chatgpt.com domain and SSL cert have been created
#79Wasn't ChatGPT already doing searches for you when relevant? For example if you asked for recent news? I can't get it to do it again for some reason it will share month old publications right now.
Re: Search.chatgpt.com domain and SSL cert have been created
#80Earlier quoted context omitted.
Ah well I like your joke, but I know GPT is moving fast, but it would be unlikely and innocent dev can change DNS records of chatgpt.com
Isn't that what DevOps is supposed to be?
well, I mean, there's a review process too, if it's done right? Something business critical (like code, keys, and I'd include DNS records) should still need two pairs of eyeballs and a process before any changes are made.
DevOps doesn't necessarily mean unrestricted control.