[webkit-dev] Unverified cert: Allow wss:// if user has accepted https:// warning? (WebKit Bug 41419)

[Mossman, Paul (Paul)]

Hi Alexey,

Definitely #1 - same certificate, same domain, and same port.

-Paul


________________________________
From: Alexey Proskuryakov [mailto:ap at webkit.org]
Sent: June 29, 2011 2:03 PM
To: Mossman, Paul (Paul)
Cc: webkit-dev at lists.webkit.org
Subject: Re: [webkit-dev] Unverified cert: Allow wss:// if user has accepted https:// warning? (WebKit Bug 41419)


28.06.2011, в 8:39, Mossman, Paul (Paul) написал(а):

Can this behaviour be implemented in WebKit as the resolution to issue 41419?

Which of the below most accurately describes what you would like implemented? Some of these would actually be WebKit issues.

1. If the user has already accepted an invalid certificate for an https document, the same certificate should be silently accepted when talking to a WebSocket server on the same domain and port.

2. If the user has already accepted an invalid certificate for an https document, any invalid certificate should be silently accepted when talking to a WebSocket server on the same domain and port.

3. If the user has already accepted an invalid certificate for an https document, any invalid certificate should be silently accepted when talking to any WebSocket server.

4. If an invalid certificate is presented for a WebSocket connection, the browser should display a confirmation dialog akin to the one for https.

5. As the only good use for invalid certificates is development, there should be an option in browser's Development menu to disable certificate checks, perhaps until browser restart or just in current window. We don't want users to make the decision whether an invalid certificate means that they are unsafe.

6. Something different.

There is a large movement in the opposite direction - browsers are going to completely block any content that is even remotely suspicious from security point of view. I am surprised that Chromium is so forgiving in this case.

- WBR, Alexey Proskuryakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110629/2f9f9bfc/attachment.html>