Re: [gentoo-user] broken seamonkey :(

[Mick]

On Sunday 06 Sep 2015 15:29:25 lee wrote:
> Mick <michaelkintzios@×××××.com> writes:
> > On Saturday 05 Sep 2015 17:22:24 lee wrote:

> >> Maybe that only works with firefox?
> >
> > Yes, it seems to be the case that SeaMonkey has some GUI differences to
> > Firefox.  I am on Firefox-38.2.1 at present.
>
> Does Firefox even have a MUA built in?  IIRC it's only the web browser
> part of seamonkey.

No, but T'bird uses the same SSL certificate storage as the mozilla browser 
does.


> > I can't recall if you tried this:
> >
> > Can you please remove it from Servers and try adding it to the
> > Authorities tab?  Your version may have additional verification checks
> > for self-signed certificates, because they essentially acting as their
> > own Root CAs.
>
> Yes, I tried that.

Right, I saw your email.  From what I can gather this is a bug impairing 
critical functionality of the Mozilla suite.


> > The fact that it is hanging and not obtaining the certificate makes me
> > wonder if you need to specify a domain name in the CN field of the
> > certificate, identical to the full URI that the client is trying to
> > connect to.
>
> That brings us back to the impractical idea of trying to bind a
> certificate to a specific fqdn or IP, or to a number of those.
>
> Is it possible to create a certificate that doesn't use either but a
> wildcard only?  I don't understand why or how an fqdn/IP in a
> certificate could or should be relevant at all.

It is relevant because Mozilla will read the CN and or subjectAltName fields 
for DNS/IP to match against the URL the client is trying to connect to.  It 
will also read any additional fields for OCSP and CRL URIs and try to connect 
to those too to retrieve relevant files (e.g. of revocation lists).  These 
would be contained in the certificate's X509v3 extensions.  The browser does 
not extrapolate from what is contained in those fields, but treats their 
contents literally.  If the CN field contains 'example.com' but the client is 
trying to connect to 'www.example.com' (or the server redirects to the latter) 
the browser's verification engine could throw its arms up and say STOP!  This 
is not the address specified on the certificate, therefore you could be 
inadvertently trying to connect to a malicious server impersonating your 
server.  The browser is warning about a Man In The Middle attack.  This is 
fine and as it should be.  What is not at all fine is that it stops you 
connecting AND it does not allow you to acknowledge as acceptable whatever it 
is that it doesn't like about your certificate.


> When creating the certificate, I have used the fqdn the host does
> actually have and knows itself by (because I needed to fill in the
> fields, and it seemed most reasonable to use the actual host name).
>
> That this host can be reached at all, via different fqdns and IPs, is a
> matter of network traffic (re-)direction and of how the DNS-entries
> currently happen to be.  They are all transparent and irrelevant to the
> user/client and subject to change.  Why should they matter for a
> certificate which is supposed to let me figure out whether I'm
> connecting to the host I'm expecting to connect to, or to something
> else?
>
> When a friend calls you on the phone, you do not insist that they are
> not your friend and reject their call just because they're calling you
> from a different phone number.  You do not reject their call and insist
> that they are not your friend because the call has been (re-)directed
> over a satellite or goes through an asterisk server.  You do not insist
> that your friend is someone else when they show up at your door wearing
> different cloths than they usually do.  Instead, you figure out that the
> caller, or the person at your door, is your friend by the human
> equivalent of a certificate.


Well, in the UK we have a feature called 'Caller ID'.  You will be surprised 
at the number of voice mails I have to leave when I call from a 'caller ID 
witheld' phone.  People will NOT answer unless they recognise the number of 
the caller.  :-)

With a server the FQDN is much more important, as it can impersonate e.g. you 
Bank and steal login information about your login details.

-- 
Regards,
Mick