> Less chance of noticing a changed certificate? Only if you blindly accept > dialogs without reading it. Do you? > Because if you take care of reading it every time it's presented the > chance of noticing any change is higher, unless your memory works the > opposite of the rest of the people and degrades by reinforcement.
wrong. ----- BEGIN DIALOG ----- The SSL certificate of sasl.smtp.pobox.com cannot be verified by the following reason: unable to get local issuer certificate Server certificate: Subject: /C=US/O=sasl.smtp.pobox.com/OU=GT50531025/OU=See www.geotrust.com/resources/cps (c)07/OU=Domain Control Validated - QuickSSL (R)/CN=sasl.smtp.pobox.com Issuer: /C=US/O=Equifax Secure Inc./CN=Equifax Secure Global eBusiness CA-1 Do you accept this certificate? ----- END DIALOG ----- there's no cryptographic hash (sha1, md5) displayed for the certificate, just certificate text fields (that any worthwhile man-in-the-middle tool uses to generate a fake cert on-the-fly), so please explain to me how you are verifying the certificate hasn't changed since the last time you had sylpheed accept it? short of manually verifying the certificate and adding it to ~/.sylpheed-2.0/certs/, you can't guarantee the certificate is unchanged between sylpheed instances based on the information presented in the dialog box. currently sylpheed (2.4.7-1) doesn't look in /etc/ssl/certs (only ~/.sylpheed-2.0/certs/; note to self: file that bug), so the above dialog is displayed despite the appropriate CA cert being installed system-wide. after that bug gets fixed, it would be nice if sylpheed displayed a hash of the certificate when asking a user to accept it (so the user can verify it, maybe with a quick phone call, or at least that it hasn't changed since last time). after that, it would be super-duper if sylpheed saved accepted certificates to ~/.sylpheed-2.0/certs for future use (with maybe a big fat warning/disclaimer to insure the user knows and accepts the danger of trusting an unverified cert). but in the mean time, here's my non-code contribution/solution to the problem (though i'm not sure if this silences, for better or worse, potential hostname-mismatch or expired-cert warnings/errors)... ps see following email. corey -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
