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

[Mossman, Paul (Paul)]

Hi all,

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.

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

-Paul


> -----Original Message-----
> From: webkit-dev-bounces at lists.webkit.org 
> [mailto:webkit-dev-bounces at lists.webkit.org] On Behalf Of 
> Mossman, Paul (Paul)
> Sent: June 29, 2011 1:33 PM
> To: Adam Barth
> Cc: webkit-dev at lists.webkit.org
> Subject: Re: [webkit-dev] Unverified cert: Allow wss:// if 
> user has accepted https:// warning? (WebKit Bug 41419)
> 
> 
> Thanks Adam!
> 
> I've filed an Enhancement with Apple: Bug ID# 9697244.
> 
> -Paul
> 
> 
> > -----Original Message-----
> > From: abarth at gmail.com [mailto:abarth at gmail.com] On Behalf Of Adam 
> > Barth
> > Sent: June 28, 2011 1:28 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)
> > 
> > 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 at 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 at avaya.com
> > >
> > > _______________________________________________
> > > webkit-dev mailing list
> > > webkit-dev at lists.webkit.org
> > > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> > >
> > >
> > 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>