Search.chatgpt.com domain and SSL cert have been created(search.chatgpt.com) |
Search.chatgpt.com domain and SSL cert have been created(search.chatgpt.com) |
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 names is so annoying.
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 will consider it too dangerous to allow.
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…
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.
"Certificate Transparencyis an open framework which helps log, audit and monitor publicly-trusted TLS certificates on the Internet. This tool lets you search for certificates issued for a given domain and subscribe to notifications from Facebook regarding new certificates and potential phishing attacks."
most commercial offerings are about monitoring your own domain, e.g. from cloudflare, sslmate, etc.
Some creators also seem to suggest they know what is going on, youtube mattvidpro hinted at it when talking about the gpt2-chatbot, he mentioned he knew something but couldn't talk about it or get sued.
I'd say "just chatgpt it"? is closer to being in the lexicon and this url just doesn't roll off the tongue
>"here let me search.chatgpt that for you"
There I was hoping sama-gpt5-chatbot had some creativity chops for naming new things but they must have decided not to use it this time.
Why would you say it like that though? You don't set "let me google.com that for you"
In the same way you don't say "let me chat.openai it for you", likely search.chatgpt.com will just become the new default interface to chatgpt, and "to chatgpt" something will mean to look it up on search.chatgpt.com
Compare this to what I would have to do with google. Open browser, type the query, guess which of the top 10 results are likely to answer the issue I was having. Click few link to open them in new tab. Read though it to see if the correct problem was being discussed. If not see another link in the top 10 list. Repeat.
I even thought where in that interface, Microsoft could place the future ads. It's totally in the realm.
EDIT: At this point, ChatGPT is basically old school "I am feeling lucky" on steroids.
I've noticed an interesting pattern: before releasing LLaMA 3, OpenAI provided access to ChatGPT 3.5 without requiring registration.
Meta might also follow this path with its own search engine. Did you know that you can now ask questions directly on Instagram and receive answers from Meta AI using LLaMA 3?
Why go elsewhere for information when you can easily find it in the app you use every day?
I am guessing that this falls under the "we will steamroll" clause of OpenAIs gradual move towards AGI.
So the money will come in, that or that way.
This is outdated. I repeated your experiment with Google query [how do I print from Autodesk] and the top result is the step by step instructions (not a link but the actual instructions, with a link to the source following). The second result is a link to Autodesk's own help docs for the print function. No ads above the fold.
But you make a point that people will keep assuming what they want to anticipate how the search will unfold, and I admit this is in part due to the enshittified commercial and news-related (and other) results, the bias is coming from somewhere, right? But I would encourage anyone to at least verify this assumption before posting it as fact.
So actually, what Copilot does is to prefilter and condense results. If I like it and it seems legit, it's enough to get my answers. Sometimes I take up the source. Most of the times I reprompt Copilot to list me alternatives and find errors in them. That discloses erroneous things like contradictions enough.
But what's more useful is "how can I mix up two dictionaries with different keys one by one into a set."... 20 seconds later, I can read how and don't have to search SO for whole 20 minutes of reading.
But yes, it will impose the same changes as Google did. Before Google, you should know where you get the information needed or already have it in your hrad/learned. After Google, you don't have to. So everyone changed into stupid mode but being way more productive. So, I fear, that's the next wave of stupid:)
Me: How to add missing monochrome.ctb file in autodesk dwg trueview?
[Upto this part google is same. Pointing to the same link, but not showing any steps though.]
Copilot: Here are the steps. Put them here in this folder......
Me: I put it there as suggested. Still didn't work. How to make tureview refer another folder location?
Copilot: Here are the steps.
Me: It worked thank you. [I really thanked it ;)]
DevOps doesn't necessarily mean unrestricted control.
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 effective balance against compromised CAs and governments that might abuse CAs, because it causes such attacks to become quickly tamper-evident.
I don't think it would be possible for a system like this to be effective without publishing the actual certificate to the log.
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).
Public CT logs mean that the property of transparent certificate issuance extends to the entire Internet, which is good. If you want private certs, you can use a private CA and deploy it to the machines in your domain. Totally reasonable alternative in my opinion.
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.
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.
Dave can test his stuff on a newly bought domain for testing or the internal domains.
Yours is not an argument against wildcard certificates! Yes, like, everything else ever, wildcard certificates can be misused.
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.
every branch
* several test data sets
* several feature flag / configuration sets
* ...
Having domain-constrained sub-CA certificates granted by the exact same mechanism we use for wildcard certs today would combine the advantages of both.
They were proposed here as an alternative to domain-restricted sub-CAs, but GP and me have given counterexamples as to why they're not (or at least not without downsides).
> No one is saying wildcard certificates should be mandatory.
Nor am I saying they shouldn't ever be used.
You may interpret it differently, but to me:
> 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.
Essentially means "default to a wildcard." My example is absolutely a good reason why you should not default to a wildcard. There are situations where they make good sense. I use them myself. It's a terrible idea to use them everywhere and always, which is usually what ends up happening when wildcard certs are the default approach.
Recommending encouraging non-wildcard certs is the optimal strategy. Only thing I would add, is recommending default to non-wildcard and evaluate deviations case by case.