Opened 13 years ago

Last modified 7 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 13 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 13 years ago by andersk

It turns out that none of those solutions work.

comment:3 Changed 13 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 7 years ago by andersk (previous) (diff)

comment:4 Changed 13 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 13 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 12 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.

Version 0, edited 12 years ago by geofft (next)

comment:7 Changed 12 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 7 years ago by andersk (previous) (diff)

comment:8 Changed 11 years ago by ezyang

  • Priority changed from normal to major

Poke.

comment:9 Changed 11 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.