Hello Mick, you wrote (Sun 2013-Dec-22 09:05:25 +0000):
> On Saturday 21 Dec 2013 20:50:39 Marcus C. Gottwald wrote: .. > > The server admin generated a new self-signed certificate and installed > > it, and what surprised me was that Mutt immediately accepted the > > new certificate without prompting me. (I had expected to be asked > > "(r)eject, accept (o)nce, (a)ccept always", verify the fingerprint, > > then choose "a".) It took me a while to figure out that this behaviour > > probably was to be expected, because the new certificate was issued > > by the same issuer as the old certificate (same name, same key), and > > Mutt trusts the old certificate (in local storage) for use as a CA > > certificate. > > As I understand it, this is only a partially correct assumption. Mutt will > trust any certificates you have accepted by pressing (a)... Yes, unless such certificate has expired, as far as I have observed. (Since when that happened, Mutt started prompting me.) > ... If you had > accepted the old CA then any new certificates signed by it would be > automatically accepted too. > > A self-signed certificate is de facto a CA of itself. If it is used to sign > another certificate then it becomes a CA of the other certificate too. That appears to be the first half of the crux of the matter: Trusting a self-signed certificate C has the effect of trusting every certificate signed by certificate C. (The other half is that expired certificates are still trusted as signing certificates.) > For your scenario to be true the ISP would have to have used the old > certificate which you had accepted already, as the CA for the new > certificate. > It is unlikely that he would have done this, if the old certificate had > expired or was about to expire... My guess is that he simply repeated the last step performed during the creation of the previous self-signed certificate. I know that he had been given the typical explanation of »1. create a key; 2. create a CSR; 3. send the CSR to a CA trusted by your users and have it issue a certificate« and »instead of steps 2 and 3, "openssl req -x509" will generate a self-signed certificate (based on the key provided as "-key")«. I verified that on a personal mail server: A newly generated self- signed certificate created using "openssl req -x509 -key oldkey.pem -out newcert.pem -days 123 -new" was immediately accepted by Mutt which had a copy of an old certificate generated exactly the same way (= same "oldkey.pem" file, same value for subject/issuer) in its "mutt_certificates" file. (The admin's approach may not have been very clever on the crypto side, but (a) I can't change that but would like to be as cautious as possible and (b) the problem of Mutt trusting an expired (self- signed) certificate as signing certificate (for a certificate based on the same key) remains.) > ... A quick check using openssl or gnutls will > verify which certificate has been signed with what, before we drown in > erroneous assumptions. Looking at a textual representation of the two certificates' field values (using "openssl x509 -text"), I see differences in "Serial Number", "Validity", "serial" field of "X509v3 Authority Key Identifier", and the signature field. All other fields contain the same values, notably "Issuer", "Subject", subject public key, and "keyid" of "X509v3 Authority Key Identifier". We know that both certificates are self-signed, so the identity of subject and issuer must be machine-recognizable. Since the subject of the old certificate is purposely trusted as the issuer of the new certificate, I guess the behaviour is to be expected (ignoring the fact that the old certificate has expired). > the drive is stolen and the private key is kept in the same drive, the key > could be used with the unexpired CA certificate to sign other certificates > under the following scenarios: > > 1. The private key had not been encrypted. > 2. The passphrase is cracked by brute force, or is known because the sysadmin > left it unencrypted in the same drive - e.g. under "My Secrete passwords.txt" Let's assume that the server machine is supposed to be able to reboot on its own, and whatever secret is required is somehow available without manual interaction. The more interesting part actually is to assume that the admin or one of his helpers turns evil, I think. And even if they don't and always take great care, sh*t happens and a key (which was only ever used for a certificate that expired long ago, so there should be no need to make a big fuzz) may become available to someone who shouldn't have it. > ... If it only uses the local mutt > certificates store to compare and contrast certificate validity, then any > certificates that are no longer valid should be removed manually. Let's assume that I don't trust any CA, told Mutt to not trust any sytem-wide stuff, and only use the local "mutt_certificates" file. But I presume that Mutt will always use the "mutt_certificates" file in addition to the system-wide information, which would mean that everybody should regularly check their "mutt_certificates" file for expired certificates and remove them, right? > ... you should only include certificates that you trust in > the ~.mutt/certificates store and make sure that you remove any which you > don't. So there's the crucial point again: How do I tell Mutt to trust a specific self-signed certificate for the purpose of authenticating the subject it was issued for, but not for the purpose of verifying another certificate? > You can use separate certificate stores for each of your imaps accounts ... I'll probably do this to avoid a cross-account authentication weakness (when being presented a server certificate signed by a certificate I only want to trust for the purpose of authenticating a server, not for the purpose of signing other certificates); but this will not help against a man-in-the-middle attack using a newly generated self-signed certificate based on a no-longer-supposed-to- be-used key which is trusted by Mutt because I once chose to trust a self-signed certificate, which (may have expired a long time ago but) is still present in "mutt_certificates". > I suggest that you use 'openssl s_client -showcerts' or equivalent to connect > and check what each server is sending and manually compare the fingerprint of > the Issuing Authority... I'm not sure I understand that suggestion: How do I retrieve a fingerprint of the Issuing Authority? I can fetch the whole certificate, I can get a fingerprint of the whole certificate (which differs from the old self-signed certificate to the new one), and I can compare the certificates' contents as described above. Which fields should I look at? Thanks again and happy holidays, Marcus -- Marcus C. Gottwald · <m...@cheers.de> · https://cheers.de
