RFC 2818 wildcard rationale

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC 2818 wildcard rationale

Chris Richardson-9
RFC 2818 states:

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.

I was trying to figure out the rationale behind this, but have been
unable to do so.  I was hoping someone could enlighten me.

Suppose that:
(1): *.example.com matched a.b.example.com
(2): *.example.com matched example.com.

What security problems exist with (1) and/or (2) that are solved by
following the rules of 2818?  Anything more than preventing a single *
from matching the entire internet?


 -- Chris
_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: RFC 2818 wildcard rationale

Yngve N. Pettersen (Developer Opera Software ASA)
On Tue, 01 May 2012 13:45:58 +0200, Chris Richardson  
<[hidden email]> wrote:

> RFC 2818 states:
>
> 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.
>
> I was trying to figure out the rationale behind this, but have been
> unable to do so.  I was hoping someone could enlighten me.
>
> Suppose that:
> (1): *.example.com matched a.b.example.com
> (2): *.example.com matched example.com.
>
> What security problems exist with (1) and/or (2) that are solved by
> following the rules of 2818?  Anything more than preventing a single *
> from matching the entire internet?

Regarding #1, if * matched multiple labels, it would match  
www.yourbank.com.whatever.example.com, which would be a very bad thing  
since it can mislead users into thinking that they are visiting  
"www.yourbank.com".

Regarding #2, I don't think that would introduce any real badness, except  
having to edit the rulestring, which make already complex logic more  
complex, and more likely to fail an unsecure manner (there is also the  
fact that you can have "f*.example.com", which should not allow #2 to be  
generated, causing more complexity). However, adding a separate rule for  
"example.com" in the SAN field is very simple.

--
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer     Email: [hidden email]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
********************************************************************
_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: RFC 2818 wildcard rationale

stpeter
On 5/1/12 6:06 AM, Yngve N. Pettersen (Developer Opera Software ASA) wrote:

> On Tue, 01 May 2012 13:45:58 +0200, Chris Richardson
> <[hidden email]> wrote:
>
>> RFC 2818 states:
>>
>> 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.
>>
>> I was trying to figure out the rationale behind this, but have been
>> unable to do so.  I was hoping someone could enlighten me.
>>
>> Suppose that:
>> (1): *.example.com matched a.b.example.com
>> (2): *.example.com matched example.com.
>>
>> What security problems exist with (1) and/or (2) that are solved by
>> following the rules of 2818?  Anything more than preventing a single *
>> from matching the entire internet?
>
> Regarding #1, if * matched multiple labels, it would match
> www.yourbank.com.whatever.example.com, which would be a very bad thing
> since it can mislead users into thinking that they are visiting
> "www.yourbank.com".

True. But * matches only the left-most label, so a.b.example.com doesn't
match *.example.com.

Peter

--
Peter Saint-Andre
https://stpeter.im/


_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: RFC 2818 wildcard rationale

Chris Richardson-9
In reply to this post by Yngve N. Pettersen (Developer Opera Software ASA)
> Regarding #1, if * matched multiple labels, it would match
> www.yourbank.com.whatever.example.com, which would be a very bad thing since
> it can mislead users into thinking that they are visiting
> "www.yourbank.com".

Are there any circumstances under which an (individual/organization)
is authorized to have a certificate for *.example.com, but is not
authorized to have a certificate for
www.yourbank.com.whatever.example.com?

> Regarding #2, I don't think that would introduce any real badness, except
> having to edit the rulestring, which make already complex logic more
> complex, and more likely to fail an unsecure manner (there is also the fact
> that you can have "f*.example.com", which should not allow #2 to be
> generated, causing more complexity). However, adding a separate rule for
> "example.com" in the SAN field is very simple.

If both (1) and (2) were allowed, that would eliminate the need for
wildcards which should simplify the logic.

And out of curiousity, are there any real examples of f*.example.com
certificates?  Are there any circumstances under which that is a good
idea?
_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: RFC 2818 wildcard rationale

Martin Rex-2
Chris Richardson wrote:

>
> > Regarding #1, if * matched multiple labels, it would match
> > www.yourbank.com.whatever.example.com, which would be a very bad thing since
> > it can mislead users into thinking that they are visiting
> > "www.yourbank.com".
>
> Are there any circumstances under which an (individual/organization)
> is authorized to have a certificate for *.example.com, but is not
> authorized to have a certificate for
> www.yourbank.com.whatever.example.com?

That is an "interesting question" (not on DANE's radar so far).

Being authorized (as being the domain owner) does not mean that every
commercial/public CA will issue a TLS server certificate for such a name.

AFAIK, at least some of the CAs will refuse to issue TLS server certs
to owners of domains that could be used for typo-squatting high-profile
sites/domains.

The issue that Yngve mentioned is about the common behaviour of
DNS resolvers to have a "default domain" or "searchlist" which they
use to complete a hostname that does not have a trailing dot before
trying to resolve that name via DNS.


>
> > Regarding #2, I don't think that would introduce any real badness, except
> > having to edit the rulestring, which make already complex logic more
> > complex, and more likely to fail an unsecure manner (there is also the fact
> > that you can have "f*.example.com", which should not allow #2 to be
> > generated, causing more complexity). However, adding a separate rule for
> > "example.com" in the SAN field is very simple.
>
> If both (1) and (2) were allowed, that would eliminate the need for
> wildcards which should simplify the logic.
>
> And out of curiousity, are there any real examples of f*.example.com
> certificates?  Are there any circumstances under which that is a good
> idea?

There is a huge variety of different behaviour in the installed
base with respect to wildcard matching from rfc2818 Section 3.1
server endpoint identification.

Adding more options at this point would only lead to further divergence
of the behaviour (=less predictable) in the installed base,
so I consider it a bad idea.

Limiting the options to what is easy to understand and explain,
and supported by a significant fraction of the installed base,
seems much more reasonable at this point.


-Martin
_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls