1 |
Mick <michaelkintzios@×××××.com> writes: |
2 |
|
3 |
> On Sunday 06 Sep 2015 15:29:25 lee wrote: |
4 |
|
5 |
> [...] |
6 |
>> |
7 |
>> Is it possible to create a certificate that doesn't use either but a |
8 |
>> wildcard only? I don't understand why or how an fqdn/IP in a |
9 |
>> certificate could or should be relevant at all. |
10 |
> |
11 |
> It is relevant because Mozilla will read the CN and or subjectAltName fields |
12 |
> for DNS/IP to match against the URL the client is trying to connect to. It |
13 |
> will also read any additional fields for OCSP and CRL URIs and try to connect |
14 |
> to those too to retrieve relevant files (e.g. of revocation lists). These |
15 |
> would be contained in the certificate's X509v3 extensions. The browser does |
16 |
> not extrapolate from what is contained in those fields, but treats their |
17 |
> contents literally. If the CN field contains 'example.com' but the client is |
18 |
> trying to connect to 'www.example.com' (or the server redirects to the latter) |
19 |
> the browser's verification engine could throw its arms up and say STOP! This |
20 |
> is not the address specified on the certificate, therefore you could be |
21 |
> inadvertently trying to connect to a malicious server impersonating your |
22 |
> server. The browser is warning about a Man In The Middle attack. This is |
23 |
> fine and as it should be. |
24 |
|
25 |
Thank you for the explanation. I'm like entirely omitting this part |
26 |
because when I do accept a certificate (i. e. add an exception), I have |
27 |
done so. That's all there is to it. |
28 |
|
29 |
Actually, I'm doing it on a LAN. I can look at the certificate and see |
30 |
if it looks ok. If there was someone in between me and the server, I'd |
31 |
be having far more serious problems than not being able to add an |
32 |
exception. So the part I'm omitting isn't relevant as long as a warning |
33 |
comes up when the certificate I previously accepted suddenly doesn't |
34 |
match anymore. |
35 |
|
36 |
But having that said, I probably need to change my way of thinking: If a |
37 |
user goes somewhere with their laptop and gets that warning, chances are |
38 |
that they will add an exception, and bad things might happen. |
39 |
|
40 |
Using a CA certificate won't stop them, though. Now what? |
41 |
|
42 |
> What is not at all fine is that it stops you connecting AND it does |
43 |
> not allow you to acknowledge as acceptable whatever it is that it |
44 |
> doesn't like about your certificate. |
45 |
|
46 |
Indeed --- fortunately, this problem is solved with seamonkey 2.35. |
47 |
|
48 |
|
49 |
> [...] |
50 |
>> When a friend calls you on the phone, you do not insist that they are |
51 |
>> not your friend and reject their call just because they're calling you |
52 |
>> from a different phone number. |
53 |
> [...] |
54 |
> |
55 |
> Well, in the UK we have a feature called 'Caller ID'. You will be surprised |
56 |
> at the number of voice mails I have to leave when I call from a 'caller ID |
57 |
> witheld' phone. People will NOT answer unless they recognise the number of |
58 |
> the caller. :-) |
59 |
|
60 |
Some people do that here, too. It's their problem, not mine. Besides, |
61 |
I was told that the caller number is easy to fake, which people found |
62 |
relevant with faxes. |
63 |
|
64 |
> With a server the FQDN is much more important, as it can impersonate e.g. you |
65 |
> Bank and steal login information about your login details. |
66 |
|
67 |
Still I have no way to verify whether I'm connected to the server I |
68 |
think I'm connected to or not (i. e. the bank or someone else). Sure, I |
69 |
might be asked to add an exception and thus be alarmed --- but unable to |
70 |
verify. |
71 |
|
72 |
So turning this the other way round: Can I *prevent* users from being |
73 |
able to add an exception (at least by making it rather difficult for |
74 |
them)? Assuming that I would create a CA certificate and import it for |
75 |
each user, and use certificates signed with it, I'd like to have some |
76 |
way to prevent them from adding exceptions. |
77 |
|
78 |
|
79 |
-- |
80 |
Again we must be afraid of speaking of daemons for fear that daemons |
81 |
might swallow us. Finally, this fear has become reasonable. |