Thanks Adam! I've filed an Enhancement with Apple: Bug ID# 9697244. -Paul

-----Original Message----- From: abarth@gmail.com [mailto:abarth@gmail.com] On Behalf Of Adam Barth Sent: June 28, 2011 1:28 PM To: Mossman, Paul (Paul) Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Unverified cert: Allow wss:// if user has accepted https:// warning? (WebKit Bug 41419)

This isn't a WebKit issue. It's an issue for the embedding application. You'll need to file a bug with the relevant browser vendor. For Apple, you can use https://bugreport.apple.com/ or Chromium, you can use http://new.crbug.com/

Good luck! Adam

On Tue, Jun 28, 2011 at 8:39 AM, Mossman, Paul (Paul) <paulmossman@avaya.com> wrote:

...

Hi all,

I originally sent this to webkit-help, but I probably should have posted it here instead.

I'd like to request an alternate resolution to the following issue:

    https://bugs.webkit.org/show_bug.cgi?id=41419 We should log the reason when a secure wss WebSocket connection could not be established

        (was: Secure wss WebSocket connections cannot be established)

Consider an example https://appliance.example.com, which uses a self-signed SSL certificate.  iOS Safari will warn the user:

          Cannot Verify Server Identify

          Safari can't verify the identity of "appliance.example.com".

          Would you like to continue anyway?

          Cancel / Details   /   Continue

The user chooses to "Continue".  Safari then trusts the identity of "appliance.example.com", and proceeds.  The resulting HTML may spawn additional https:// requests, which will also proceed.

Suppose though that a wss:// connection to "appliance.example.com" is initiated.  As issue 41419 states, this will fail in Safari and WebKit (r87480.)

Chrome on the other hand, consider the user's acceptance of the server's identity as valid for both wss:// and https:// connection.  This seems reasonable.  The user accepted the server's identity, with no caveat on the protocol.

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

-Paul

paulmossman@avaya.com

_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

12.07.2011, в 11:15, Mossman, Paul (Paul) написал(а):

On a related note, we've found that as of iOS 4.3.3 Mobile Safari will also not play .wav files under the same conditions. (Unverified SSL cert, manually accepted by the user.) The error is:

"The Movie cannot be played."

I've updated ID# 9697244 at http://bugreport.apple.com.

Please file a new bug at http://bugreport.apple.com for that issue. It's always easier to mark bugs as duplicates than to split them if we want to make such adjustments later. - WBR, Alexey Proskuryakov

On Jul 12, 2011, at 11:15 AM, Mossman, Paul (Paul) wrote:

But can anyone see a good reason why a browser would refuse to play a .wav file, but happily render .html, .jpg, .css, etc?

This is not an appropriate question for webkit-dev as it is not a question about the development of WebKit. A good place to get answers about this are in the iOS Dev Center and Safari Dev Center. Generally speaking, media playback on webpages has to be user-initiated in iOS. This is covered in various Apple documentation, such as Safari HTML5 Audio and Video Guide, but typically that concentrates on the <audio> element rather than directly loading a wav file. But please don’t ask followup questions about this on this mailing list, since it’s off topic for the list. -- Darin

Hi Alexey, Definitely #1 - same certificate, same domain, and same port. -Paul ________________________________ From: Alexey Proskuryakov [mailto:ap@webkit.org] Sent: June 29, 2011 2:03 PM To: Mossman, Paul (Paul) Cc: webkit-dev@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