Bug 85237

Summary: No special warning given when the https ssl certificate for a site changes
Product: [Unmaintained] kio Reporter: Chris Morris <c.i.morris>
Component: ksslAssignee: Konqueror Developers <konq-bugs>
Status: CONFIRMED ---    
Severity: normal    
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Debian testing   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Chris Morris 2004-07-15 10:55:01 UTC 
Version:            (using KDE KDE 3.2.2)
Installed from:    Debian testing/unstable Packages
OS:                Linux

If the https certificate for a web site changes, there is no special warning given. To reproduce:
1 - Set up a https web server, making your own one-off certificate and CA for the purpose.
2 - Connect to this web server with Konqueror. The message "The server certificate failed the authenticity test (hostname)" will appear.
3 - Connect to the server. This will store a certificate in the peer SSL certificates store.
4 - Optionally, tell it to always accept that certificate.
5 - Make a new one-off certificate and CA for the web server, and restart the web server.
6 - Restart Konqueror and connect to the web server again. The message received is exactly the same as in step 2.

This is the problem - there is no warning given that the certificate has *changed* - a common sign of a man-in-the-middle attack. Compare this to the behaviour of ssh, for example:
cim@dinopsis:/usr/home/cim$ ssh mitm
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
...etc...

After following the steps above I have two *different* certificates for the same host in my certificate store. I feel that Konqueror should give a much stronger warning in this situation.

Thanks
Comment 1 George Staikos 2004-11-02 00:23:27 UTC 
I don't think so.  Certificates change regularly.  No other browser warns, and I don't think we should either.
Comment 2 Chris Morris 2004-11-02 11:31:46 UTC 
On Mon, 1 Nov 2004, George Staikos wrote:
> I don't think so.  Certificates change regularly.

Certificates may change regularly, but there are safe changes and there
are dangerous changes. Only the dangerous changes need warnings.

Where I say 'untrusted CA' this always applies equally to the 'no CA'
case.

1) Change from a certificate signed by a trusted CA to another certificate
signed by the same CA. Safe.
2) Change from a certificate signed by a trusted CA to a certificate
signed by a different trusted CA. Safe.
3) Change from a certificate signed by a trusted CA to a certificate
signed by an untrusted CA. Dangerous.
4) Change from a trusted certificate signed by an untrusted CA to another
certificate signed by the same untrusted CA. Possibly dangerous.
5) Change from a trusted certificate signed by an untrusted CA to another
certificate signed by an untrusted CA. Dangerous.
6) Change from an untrusted certificate to a certificate signed by a
trusted CA. Safe
7) Change from an untrusted certificate to another untrusted certificate.
Possibly dangerous.

I would guess that the majority of *legitimate* certificate changes taking
place are of types 1 and 2, for which no warning needs to be given.

Say mybank.com has a certificate signed by Integrity Corporation, who I
trust as a CA.  Users don't need warning if it changes to a different
certificate signed by Integrity Corporation, or a different certificate
signed by another trusted CA.

Users *do* need a big warning if the certificate changes to one signed by
the untrusted Joe Cracker CA.

> No other browser warns, and I don't think we should either.

Then it's a bug in other browsers as well (and bugs have been filed on
this issue for some of them).
Comment 3 Justin Zobel 2021-03-10 00:15:29 UTC 
Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.