645161 - Idea: Display warning if secure site switches to different CA, allow SSL handshake based CA transition

Status: RESOLVED WONTFIX

(Core :: Security: PSM, defect)

Description

[Kai Engert [:KaiE:]]

I'm trying to come up with some ideas.
Let me know if you think this isn't helpful.

- first visit to https://www.site.test
  site uses a CA with Subject Name = "CN=Trusted CA 1, ..."

- if cert is valid, PSM persistenly remembers the following association:
  { "www.site.test" , "CN=Trusted CA 1, ..." }

- user visits site again, lookup what we have remembered,
  compare Subject name of CA.

- if sites uses a cert from a different issuer,
  throw up big warning, explain to user

Would this help?

Could we educate sites that they should announce to users if they make a change in the CA that assures their identity?

Should Secure Sites commonly have a banner that mentions the company that identify them?

Could this help to build an association in user's minds?


We could invent a mechanism, which a site could use to "prepare and announce" their migration to a separate CA.


For example, we could define that SSL servers are allowed to send out more than one valid server certificate.

When transitioning to a different CA certificate (even different intermediate within the same CA company),

for the duration of a transition period (e.g. 1 month), 

during the SSL handshake, a site could send both the old and the new server certificate.


If the SSL client (Mozilla) finds more than one certificate,
it could check if one of the valid server certificates matches what we have remembered.

If it matches, and the new server cert is valid too,
we could create remember it as a new additional, allowed association.


At a future time, when the old certificate is no longer being sent,
the new cert can be accepted without warning.

Comment 1

[Kai Engert [:KaiE:]]

What's the benefit of this idea?

The idea does not help, if an attacker is able to hack into the CA usually used by the attacker.

However, if suddenly a different CA issued a cert, whether by a hacker or in a state-attack scenario, the change would be detected.

Comment 2

[Eddy Nigg (StartCom)]

This discourages subscribers of an existing CA to switch to a different and perhaps better CA just for this reasons. I'd rather oppose such an idea.

What needs to be done is strengthen the CA issuance practices and enforce compliance. See [e-mail]

Comment 3

[Kai Engert [:KaiE:]]

(In reply to comment #2)
> This discourages subscribers of an existing CA to switch to a different and
> perhaps better CA just for this reasons. I'd rather oppose such an idea.

Please look at the second part of my writing.

I propose a technical mechanism that could be used to avoid the warning.

Comment 4

[Kai Engert [:KaiE:]]

Another related idea, related to the possibility that a CA gets banned/revoked, and avoiding the consequence of sites stopping to work.

If we allowed that during an SSL handshake a server sends more than one server certificate, then:

- a site could use a "double tracked" CA strategy

- a site owner could use the same key pair / CSR,
  and request certificates from two separate CAs

- a site could always send two server certs

- if one of the CAs gets banned, the client could automatically switch over
  to the other, still working cert

I confess I haven't checked with SSL standards, if the current SSL standards allow for this idea, or whether the TLS protocols needed to be enhanced. Maybe one of you can tell us without researching?

I think at least SSL clients would have to be enhanced to look for more than one valid server cert.

Comment 5

[Eddy Nigg (StartCom)]

The average server operators have a hard time installing one cert, I think it's not feasible. Besides tell me which server software supports sending two server cert for the initial handshake?

Comment 6

[Kai Engert [:KaiE:]]

(In reply to comment #5)
> I think it's
> not feasible. Besides tell me which server software supports sending two server
> cert for the initial handshake?

I'm not talking about software that is available,
this is brainstorming about ways to make PKI better.

Comment 7

[Eddy Nigg (StartCom)]

Ah OK :-)

Sorry then...

Comment 8

[Jacob Appelbaum]

Cert Patrol already does this kind of thing, doesn't it?

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

I vehemently oppose this idea.  You do NOT want to lock users into their 
current CAs, yet that is exactly what this proposal would do.  It punishes 
those who wise up and decide to stop paying exorbitant fees.  It offers NO
way for the user to distinguish between legit and illegit changes.

Opposed.  No ifs ands or buts.

Comment 10

[Gervase Markham [:gerv]]

Kai: if you are just coming up with ideas, rather than proposing specific concrete changes, that's absolutely fine :-) but I suggest the newsgroup is a better place for having the debate.

Gerv

Comment 12

[Dana Keeler (she/her) [:keeler]]

I believe the add-on certificate patrol does this: https://addons.mozilla.org/en-US/firefox/addon/certificate-patrol/?src=search
(In any case, this probably isn't something we'd ship by default.)