Given that the security "zone" varies based on the TLD, how will the new TLS be handled?

For example: A browser may permit cookies to be shared and SSL certificates, and wildcard certificates

  • company.com ( two layers deep)
  • company.co.uk ( three layers deep)
  • local ( one layer deep)

However cookies, cross site requests and more are banned by browsers as they all apply too broadly to TLDs

  • *.com (two layers deep)
  • *.co.uk (three layers deep)


  1. With the new proposed TLDs, what will the new security scope be for both wildcard certificates, and SOP? Where is this published?

  2. Is it expected that SOP and the scope of wildcard certificates to be equal?

  3. Are there any other concerns besides SSL certificates and SOP that applies to cookies, cross site requests, javascript, localstorage, Flash, etc?


Since there is no chance of every CA supporting the same policy when issuing certificates, and SOP is really dependant on all the browsers getting a consensus, how will browsers handle this?

  • Is badly an option? Cause that'd be my guess as to how browsers will handle it. – Fake Name Aug 13 '13 at 0:06

SOP and wildcard certificates are orthogonal issues. SOP works on the names as found in URL, and don't care about what appeared in any certificate which may or may not have been involved at some point. If a script came from a URL in https://foo.example.com/ then https://bar.example.com/ will be considered as a distinct "origin", even if both use the same certificate with both foo.example.com and bar.example.com in it (or, equivalently, a wildcard name *.example.com).

Existing browsers use ill-documented restrictive rules on what wildcard names are allowed. See, for instance, this previous question. One frequent rule is that first-level and second-level wildcards are not allowed (so no *.com); new TLDs will not change anything to that. The tricky part is for "two-level" names which functionally act like TLDs, e.g. co.uk. The new TLDs are, for a large part, a way to avoid such two-level pseudo-TLDs, so it is expected that this will incur less trouble, not more.

All these games about wildcard certificates are only for SSL/TLS and have no impact at the HTTP level; SOP, cookies... don't care about wildcard names.

(Unless a browser vendor gets really creative, as they sometimes do.)

| improve this answer | |

It isn't really any fundamentally different than it is now. It would really be up to the CA to decide on their policies to ensure that they don't issue a broader certificate than the entity requesting the certificate controls. It is going to try and match the wildcard to the name of the domain in the certificate to see if it matches. They would have to determine this based on each zone and how domain names are allocated in that zone.

| improve this answer | |
  • Which is more likely - a consistent SSL name constraint (so to speak) enforced by all public CAs or by all browsers? – goodguys_activate Aug 12 '13 at 17:57
  • Yes each browser would have to determine this based on each zone and how domain names are allocated in that zone.. Does this mean that each vendor has to figure this out? Will it be consistent across vendors? Any inconsistency would imply that some TLDs are more "secure" than others. (cookie theft, etc) – goodguys_activate Aug 12 '13 at 18:05

It's my understanding that wildcard certificates only support a single level of subdomain matching. That is you cannot have matchings like *.*.com or *.*.stackexchange.com. I believe you can technically have wildcard certificates like *.com, though no certificate authority should be giving out such certificates (and they would only match for say google.com and not match with www.google.com).

Granted RFC-6125 seems to state that allowable locations of the wildcard in wildcard certificates used to not be clear and consistently defined across browsers. However, it gives clear rules for how to do it:

If a client matches the reference identifier against a presented identifier whose DNS domain name portion contains the wildcard character '*', the following rules apply:

  1. The client SHOULD NOT attempt to match a presented identifier in which the wildcard character comprises a label other than the left-most label (e.g., do not match bar.*.example.net).

  2. If the wildcard character is the only character of the left-most label in the presented identifier, the client SHOULD NOT compare against anything but the left-most label of the reference identifier (e.g., *.example.com would match foo.example.com but not bar.foo.example.com or example.com).

  3. The client MAY match a presented identifier in which the wildcard character is not the only character of the label (e.g., baz*.example.net and *baz.example.net and b*z.example.net would be taken to match baz1.example.net and foobaz.example.net and buzz.example.net, respectively). However, the client SHOULD NOT attempt to match a presented identifier where the wildcard character is embedded within an A-label or U-label [IDNA-DEFS] of an internationalized domain name [IDNA-

| improve this answer | |
  • The two levels of wildcards is almost tangential to the question I'm asking. I deleted them from my question. It's a browser bug that was exploited, and might be exploited again. My core question is about SOP and what DNS name is secure from a given peer DNS name. – goodguys_activate Aug 12 '13 at 18:02
  • Perhaps I should remove certificates from my question altogether. I'm focusing on SOP... not the construction of a wildcard cert which is already on this site. – goodguys_activate Aug 12 '13 at 18:06

Using the Public Suffix List makes this relatively easy, since this list doesn't change very often.

This is a list of all top-level and second-level domains under which people can purchase a domain name. Thus a browser needs to match only one level beyond the corresponding entry on this list to determine the domain name it should use as the origin.

This has been supported in Firefox for quite some time, and Mozilla has made the list open to anyone who wants to use it.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.