Opened 11 years ago

Last modified 5 years ago

#106 assigned defect

*.scripts.mit.edu certificate doesn't handle lockers with dots in their name

Reported by: geofft Owned by: geofft
Priority: major Milestone:
Component: web Keywords:
Cc:

Description

See, for instance, https://6.034.scripts.mit.edu:444/ or https://www.ksplicethesoftware.jbarnold.scripts.mit.edu/.

I'm not sure what the good options are here. We could

  • get a few levels of *.*.*.*.scripts.mit.edu as alternate subject names from our money-costing cert
  • get a few *.*.*.*.scripts.mit.edu certs from MIT, and do SNI
  • fix SSL upstream and wait for it to filter down into browsers in a few months

(Reported by adehnert.)

Change History (9)

comment:1 Changed 11 years ago by geofft

  • Summary changed from *.scripts.mit.edu doesn't handle lockers with dots in their name to *.scripts.mit.edu certificate doesn't handle lockers with dots in their name

comment:2 Changed 11 years ago by andersk

It turns out that none of those solutions work.

comment:3 Changed 11 years ago by geofft

Okay, how about

  • Amend the RFC (or even just the implementations) to support a cert for **.scripts.mit.edu doing what we want? Or add support for an extra something field to say "This wildcard can cover multiple levels", so it remains a cert with subject name *.scripts.mit.edu for backwards-compatibility?
Last edited 5 years ago by andersk (previous) (diff)

comment:4 Changed 11 years ago by andersk

I think the RFC people will say that what we want is our own signed CA with a Name Constraints extension of “.scripts.mit.edu”. I bet it’s approximately impossible to buy such a signature from a “real” CA (though I haven’t looked very hard), but maybe we’d have better luck with the MIT CA?

comment:5 Changed 11 years ago by xavid

A less exciting solution would be to give something like 6-034.scripts.mit.edu to the 6.034 locker and suggest they use that for https.

comment:6 Changed 11 years ago by geofft

  • Owner set to geofft
  • sensitive set to 0
  • Status changed from new to assigned

I shot Eric Rescorla, the RFC's author, this e-mail:

> Hi Eric,
> 
> I'm writing in regards to section 3.1 of RFC 2818, specifically:
> 
> > Names may contain the wildcard
> > character * which is considered to match any single domain name
> > component or component fragment. E.g., *.a.com matches foo.a.com but
> > not bar.foo.a.com. f*.com matches foo.com but not bar.com.
> 
> I'm wondering what you would recommend for a certificate that would, in 
> fact, match bar.foo.a.com as well as foo.a.com. Options that occur to me 
> include a special extension in the certificate indicating that the 
> wildcard in *.a.com should be permitted to match multiple components, and 
> issuing a certificate for **.a.com.
> 
> Because of a lack of direction in RFC 2818, browsers and libraries don't 
> implement a way to let a wildcard certificate match multiple components, 
> and websites and CAs won't come up with a certificate that no browser 
> supports -- see <http://code.google.com/p/support/issues/detail?id=2990> 
> for a specific example of this problem.
> 
> Rather than attempting to lobby for an arbitrary choice in my favorite 
> browsers, I'm curious if you have specific recommendations as the RFC 
> author, or if you're aware of other efforts or standards or drafts that 
> address this issue, so we have something on which to base 
> multiple-wildcard support in HTTPS.

Thanks,
-- 
Geoffrey Thomas
geofft@mit.edu

We'll see where it goes. One possible outcome is that he mentions that he doesn't know any solutions but thinks ** might work (it's analogous to, say, bash's syntax for globbing multiple directories), in which case I have something slightly stronger with which to lobby said favorite browsers. At that point we can get **.scripts.mit.edu as a subjectAltName.

Last edited 5 years ago by andersk (previous) (diff)

comment:7 Changed 11 years ago by geofft

Eric replies, CC'ing IETF applications area director Peter Saint-Andre, who he claims is "working on more general guidance on such issues" and suggesting the *.*.scripts solution. I mentioned that we really want the option this ticket calls "fix SSL upstream", i.e., arbitrary levels, but that *.*.scripts would be a good start.

Last edited 5 years ago by andersk (previous) (diff)

comment:8 Changed 9 years ago by ezyang

  • Priority changed from normal to major

Poke.

comment:9 Changed 9 years ago by andersk

See also #262 “Mangle locker names that are invalid hostnames and MySQL usernames”.

Note: See TracTickets for help on using tickets.