At 01:34 05/07/98 +0200, you wrote:
>Hi John,
>
>Normaly the WebBrowser checks the URL requested (in the Location Box in
Netscape)
>
>so the Webbrowser asks for www.domain.co.uk and gets a certificate that has the
>commen name of www.securedomain.co.uk , and as the two don't match up
there is a
>potential security danger there (someone is trying to be you , or someone is
>using your cert on a server he should not ..)
>
>So the Browser complains , or eaven refueses to connect ..
>
>Hope this helps
>
>Gavin
Very much. That was the missing piece for me. So if I use a wildcard in a
certificate, I'm going to be dependent on all browsers correctly expanding
the wildcard/matching the result against the URL requested. Now and for
future versions of the browsers... a recipe for disaster, I think! So I'll
not be doing this.
Adam wrote:
>It was the abstract to which I was referring - as I said, there are no
>technical drawbacks (that I can think of)... However, if a user examines
>your cert, (s)he will gain a lesser degree of comfort from something
>that says '*.thing' than from 'specific.thing'. Since domains are not
>tied to IP networks, and can therefore be anywhere, it is much easier to
>hijack '<something>.thing' than 'this.particular.machine.thing' (and
>before anyone jumps in and points out that if I can subvert the DNS of
><something>.thing, I could also do 'this.particular.machine.thing', my
>point is that a new DNS entry could go unnoticed for much longer than a
>changed one.). A 'trusted' '*.thing' cert is, therefore, a dangerous
>thing to have lying around.
I think I've got that. Can you confirm, in order to hijack a secure
(virtual) server, the miscreant has to do two things:
1) get a copy of the SSLCertificateKeyFile and the matching SSLCertificateFile;
2) spoof the DNS for name contained therein.
and then they are in business? (my business!)
>
>John Sutton wrote:
>
>> At 09:48 04/07/98 +0100, you wrote:
>> >> 5) I read somewhere that I can get a Thawte certificate (maybe anybody's
>> >> cert?) associated with a wildcard domain name e.g. *.SCL.co.uk. If that's
>> >> the case it surely makes sense to do it so that I can play around with the
>> >> names later on if necessary. Are there any drawbacks to doing that?
>> >
>> >Technically no, but you are obviously downgrading the level of trust
>> >that one can apply to the cert - you are using a generic 'site' cert, as
>> >opposed to one for that particular server, and that introduces an
>> >elelement of doubt into the trust equation. And no, you can't get
>> >anybody's - Versign, for example, specifically disallow 'special'
>> >characters.
>>
>> I'm a bit foxed by that response. I can see your point about "downgrading
>> the level of trust" _in_the_abstract_ but the nuts'n'bolts elude me! I
>> don't understand at what point in the whole process the domain name against
>> which the certificate is issued is actually referenced. This domain name is
>> presumably embedded in the certificate, and at some point (or points) this
>> name is compared to.... some other name... But which name, and by what, and
>> when??? If that's too darn complicated to explain, perhaps someone could
>> point me at some documentation.
>>
***************************************************
John Sutton
SCL Computer Services
URL http://www.scl.co.uk/
Tel. +44 (0) 1239 621021
***************************************************