borrowed heavily from the fetchmail source. this checks the fingerprint of the server against a colon separated hex string of a user specified MD5 hash. Adds configuration settings Fingerprint and CheckFingerprint.
i pushed a modified version of your patch to an experimental 'ssl-fprint' branch in the git repo.
the master branch already contains some improvements of ssl certificate handling. please verify the continued usefulness of the functionality and rebase or discard the patch accordingly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
so, now i finally looked at this. :}
the patch verifies that the fingerprint of a certificate which was already confirmed to be good matches - i'm not quite sure what this is supposed to be good for?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
huh, somehow i missed your response.
i don't really see the point. if you are worried about mbsync accepting only exactly one specific certificate, feed it via CertificateFile. that seems easier than extracting the fingerprint.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"File containing additional X.509 certificates used to verify server identities. Directly matched peer certificates are always trusted, regardless of validity.
Note that the system's default certificate store is always used and should not be specified here."
The additional and "system's default" wording makes it seem as if I wouldn't be able to tell if the server I am connecting to changes certificates or not. Only whether the certificate is valid. The heartbleed SSL bug is a good example of this feature being useful.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
this is correct, but then it would seem more in order to have an option to disable loading of the default root certificate store, rather than burdening the user with a manual check, no?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i added the SystemCertificates bool option quite a while ago. as such, i consider the underlying requirement sufficiently addressed. consistency with fetchmail isn't all that important in itself. as adding options always adds complexity to the code and documentation, it shouldn't be done unless there are strong technical reasons.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i pushed a modified version of your patch to an experimental 'ssl-fprint' branch in the git repo.
the master branch already contains some improvements of ssl certificate handling. please verify the continued usefulness of the functionality and rebase or discard the patch accordingly.
revision 2
The revised patch is against your master branch. Sorry for not doing this to
begin with.
so, now i finally looked at this. :}
the patch verifies that the fingerprint of a certificate which was already confirmed to be good matches - i'm not quite sure what this is supposed to be good for?
The original check verifys the certificate chain only. The server certificate may have been replaced with another and the patch would detect this.
Updated for v.1.1.0
huh, somehow i missed your response.
i don't really see the point. if you are worried about mbsync accepting only exactly one specific certificate, feed it via CertificateFile. that seems easier than extracting the fingerprint.
Well, I use it in conjunction with pwmd along with shared fetchmail elements and this just makes things easier is all.
The CertificateFile docs say:
"File containing additional X.509 certificates used to verify server identities. Directly matched peer certificates are always trusted, regardless of validity.
Note that the system's default certificate store is always used and should not be specified here."
The additional and "system's default" wording makes it seem as if I wouldn't be able to tell if the server I am connecting to changes certificates or not. Only whether the certificate is valid. The heartbleed SSL bug is a good example of this feature being useful.
this is correct, but then it would seem more in order to have an option to disable loading of the default root certificate store, rather than burdening the user with a manual check, no?
Either option would work. For me though, the fingerprint check is better because fetchmail uses the same method. :)
Time to close this ticket?
It it still useful to me. But ultimately up to you whether to include it or not.
i added the SystemCertificates bool option quite a while ago. as such, i consider the underlying requirement sufficiently addressed. consistency with fetchmail isn't all that important in itself. as adding options always adds complexity to the code and documentation, it shouldn't be done unless there are strong technical reasons.