Re: [TLS] Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard

[Eric Rescorla <[e-mail]>]

On Fri, Jun 1, 2012 at 2:51 PM, Geoffrey Keating <[e-mail]> wrote:
> Eric Rescorla <[e-mail]> writes:
>
>> On Fri, Jun 1, 2012 at 1:55 PM, Geoffrey Keating <[e-mail]> wrote:
>> > Eric Rescorla <[e-mail]> writes:
>> >
>> >> On Fri, Jun 1, 2012 at 12:15 PM, Yngve N. Pettersen (Developer Opera
>> >> Software ASA) <[e-mail]> wrote:
>> >> > - Update sec. 3.1 to use RFC 6125 for the server identity.
>> >>
>> >> I'm not sure I agree with this. 2818 is intended to document HTTPS client
>> >> behavior. This may or may not be what we recommend for other protocols
>> >> (and indeed, the terms under which 6125 was approved included that
>> >> it not override 2818 for HTTPS).
>> >
>> > One substantive change here is that instead of "MUST" for using the
>> > commonName field, it would become "MAY".  I think this is an
>> > appropriate change, especially given that clients will not always
>> > accept the commonName field (for example, if it contains spaces, or if
>> > it isn't in DNS 'preferred name syntax',
>>
>> I'm not sure I follow this. If the CN isn't a valid domain name, then
>> won't it fail to match the DNS name it is intended to match?
>> What am I missing?
>
> Suppose you have a cookie for ".example.com" which I'd like to steal.
> I MITM you but you're using SSL and the cookie is marked as 'secure'
> so I can't just grab it.  I manage to acquire a valid e-mail
> certificate with a common name of "[e-mail]".  Now I
> fake your DNS so that '[e-mail]' appears to be a valid
> hostname (that is, I cause your DNS request to return an A record for
> 'somename@mail' in the domain 'example.com') pointing at my server, and
> wait for you to open a non-TLS web page, in which I inject HTML which
> includes a frame or an image from
> 'https://somename%40mail.example.com/somefile'.  The cookie will be sent
> as part of this request, and it'll be sent to my server.
>
> The name 'somename@mail' is not in the 'preferred name syntax' but DNS
> will quite happily serve it---DNS labels are 8-bit strings that can
> even contain NUL characters.

OK, I see the issue. I do wonder how a browser would actually behave in this
case. I.e., I would hope that it would either parse this as
https://mail.example.com/
with a username of somename or alternately expect that the certificate contain
the %40, but regardless I agree it's not great.


> Another approach is that I could get a certificate with a common name
> of 'Some Name'.  If your DNS search path is set to include
> 'example.com' (or if I can force this by controlling your DHCP), I
> might be able to do the same thing with a URL of
> 'https://Some%20Name/somefile'.

Wouldn't this be an issue with or without a space? I.e., I get a certificate
with CN "foo" and then serve https://foo/?

-Ekr