[flagged]
Lmao what so you think the LLM is trained on? And the data set is frozen in the past because LLMs are polluting the web with generated garbage.
that's the point.
Search.chatgpt.com domain and SSL cert have been created
91–100 of 126 posts
Re: Search.chatgpt.com domain and SSL cert have been created
#92Re: Search.chatgpt.com domain and SSL cert have been created
#93Wasn'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.
That was through bing. And bing uses similar algorithms to google for ranking. OpenAI can do way better.
Re: Search.chatgpt.com domain and SSL cert have been created
#94So does that mean my chat will be publicly searchable?
No
Re: Search.chatgpt.com domain and SSL cert have been created
#95RIP Google. Yet another story of a company killed by "effective" management. The McKinsey school isn't so effective after all, is it.
Can someone tell me how all that leet coding doesn't lead to their AI having better coding ability? More fizz buzz has been spilled on google whiteboards than in any other place on earth.
Bad organization. So what if you hire good engineers if you make then do wrong tasks.
Re: Search.chatgpt.com domain and SSL cert have been created
#96Earlier 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.
I know, but what I mean is that just getting a wildcard cert and handing it to all servers that need it comes with some tradeoffs, as does requesting a single-host cert publicly for each host (mainly that I need to talk to a CA, which needs to be available, and it'll publicly log a possibly internal-only, preview etc. hostname).
Having domain-constrained sub-CA certificates granted by the exact same mechanism we use for wildcard certs today would combine the advantages of both.
Re: Search.chatgpt.com domain and SSL cert have been created
#97Earlier quoted context omitted.
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.…
It depends on the system design. If I have an organization like Google, with many employees, *.google.com would be a horrible cert.
That's not every organization.
I maintain many groups of /related/ servers (including dynamic ones which appear and disappear at whim). There, a wildcard makes a lot of sense. If I have https://[username].[domain]/, https://[git project].[domain]/, https://[client].[domain]/ or similar, that integrates nicely with a lot of security infrastructure in ways which http://[domain]/client/ don't.
E.g. A network can filter https based on domains, but can't look inside the envelope. A browser will highlight domains to users who want to know where they are. Etc.
There are also many good reasons why managing one credential per server (which can map to many domains) is better practice than managing a dizzying array of credentials.
So I agree about the general best practice, but there are exceptions. Mandating (as opposed to recommending / encouraging) non-universal best practices is usually bad practice.
Re: Search.chatgpt.com domain and SSL cert have been created
#98Earlier quoted context omitted.
Certificate Transparency needed to serve website owners and not some greater good. Knowing that someone issued wildcard is enough.
Certificate Transparency really serves the end user. Because the most popular browsers (at least Chrome and Safari) generally require CT logged certificates, if you want to successfully perform a MitM attack against any user, even just some individual user, even controlling a CA, you still can't do so without publishing your fraudulent certificate to a CT log. This is the important function of the CT log. It is an ef…
I don't follow your threat model.
Let's say that browser is fine with CT if either leaf or intermediate certificate is logged.
If you need to issue fake certificate, you need to either log it, or you need to issue fake intermediate certificate and log it.
Either way it's visible to website owner (and other people likely won't care anyway).
Re: Search.chatgpt.com domain and SSL cert have been created
#99Earlier quoted context omitted.
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…
And the beautiful thing about domains is that they're hierarchical, so you can arbitrarily split your trust boundaries.
A cert for .test.domain seems reasonable, for example, especially if the test infrastructure is dynamic, and you e.g. have CI/CD for a Cartesian product of:
every branch
* several test data sets
* several feature flag / configuration sets
* ...
Re: Search.chatgpt.com domain and SSL cert have been created
#100Earlier quoted context omitted.
There is no such thing as an "SSL certificate" or "TLS certificate". There are certificates, which are used in various protocols including SSL and TLS. You can use the same certificate for both. The name "SSL certificate" is just a shorthand indicating the intended purpose of the certificate, nothing more. As such there really is no point in being pedantic over SSL vs TLS.
More accurately they are X.509 certificates.
If we want to be pedantic, X.509 mainly defines the binary format of these certificates.