JavaFX WebView TLS/SSL Certificate Revocation Check

[Anthony Vanelverdinghe]

Hi Michael

I just tested this and everything works as expected, i.e.:
- JavaFX' WebView uses OCSP when the 3 related properties are set (using 
WireShark to verify)
- https://revoked.grc.com fails when using OCSP, and succeeds when not
- https://www.coinbase.com succeeds either way

So apparently this is something specific about your environment and/or 
application (my environment is Java 8u66 on Windows 10, and the test 
case I used is below). Therefore, I think it would be best if you'd file 
an issue at http://bugs.java.com with a minimal test case & detailed 
information about your environment. This will help the OpenJFX team to 
reproduce your issue, and help you to follow up on it.

Kind regards, Anthony

PS: the test case I ran (imports omitted for brevity):

public class TestOcsp extends Application {

     @Override
     public void start(Stage primaryStage) {
         Security.setProperty("ocsp.enable", "true");
         System.setProperty("com.sun.net.ssl.checkRevocation", "true");
         System.setProperty("com.sun.security.enableCRLDP", "true");

         WebView view = new WebView();
         primaryStage.setScene(new Scene(view, 800, 600));
         primaryStage.show();

         Platform.runLater(() -> {
             WebEngine engine = view.getEngine();
             Worker<Void> loadWorker = engine.getLoadWorker();
             loadWorker.stateProperty().addListener((property, oldState, 
newState) -> System.out.println(oldState + " -> " + newState));
//            engine.load("https://revoked.grc.com/");
             engine.load("https://www.coinbase.com/");
         });
     }

}


On 5/01/2016 1:03, mike.ennen at gmail.com (Michael Ennen) wrote:
> Kevin,
>
> After some further exploration I see that indeed certificate revocation
> does seem to be enabled through:
>
> Security.setProperty("ocsp.enable", "true");
> System.setProperty("com.sun.security.enableCRLDP", "true");
> System.setProperty("com.sun.net.ssl.checkRevocation", "true");
>
> However, this only seems to active CRL (as WireShark and oscp debug
> properties both show no OSCP related activity) and furthermore, and more
> importantly, this will cause JavaFX WebView to throw an SSL handshake
> failed message (which, by the way, could certainly be more informative and
> better implemented by passing along the exception cause Throwable instance)
> for apparent false-positives. That is, just try connected to, for example,
> https://www.coinbase.com/ with the 3 properties above enabled (it fails).
>
> Thanks,
>
> On Mon, Jan 4, 2016 at 3:23 PM, Kevin Rushforth <kevin.rushforth at oracle.com>
> wrote:
>
>> Try the following:
>>
>>     System.setProperty("com.sun.net.ssl.checkRevocation", "true");
>>
>> -- Kevin
>>
>>
>> Michael Ennen wrote:
>>
>>> Hello,
>>>
>>> I will keep this short and brief. If one attempts to use the WebView
>>> control to load the following page:
>>>
>>> https://revoked.grc.com/
>>>
>>> The page is loaded, SSL handshake completes successfully, and it is
>>> displayed and no exceptions are thrown
>>> (e.g. webView.getEngine().getLoadWorker().getException() is null) and the
>>> WorkerState goes to Worker.State.SUCCEEDED.
>>>
>>> However, the certificate of this page is indeed revoked.
>>>
>>> I understand that the WebView uses HttpsUrlConnection under the covers,
>>> and
>>> so I did some googling about OSCP/CRL (which are certificate revocation
>>> protocols, for lack of a better term). It seems that OSCP can be enabled
>>> via:
>>>
>>> Security.setProperty("ocsp.enable", "true");
>>>
>>> and, as a fallback, CRL can be enabled via:
>>>
>>> System.setProperty("com.sun.security.enableCRLDP", "true");
>>>
>>> However, neither of these make any difference in regards to the successful
>>> outcome posted above.
>>>
>>> One really disgusting workaround to this problem would be to write a
>>> TrustManager (which is extremely difficult in my estimation, and prone to
>>> error) that checks for certificate revocation (by using, for example,
>>> the sun.security.provider.certpath.OSCPChecker class) but since there is
>>> no
>>> way to hook into the validation check of an existing TrustManager, all of
>>> the existing functionality would have to be duplicated.
>>>
>>> Considering the WebView can be used essentially as a browser (especially
>>> given the fact that it is based on WebKit) I think this is quite a serious
>>> issue (and indeed is a serious issue for my particular application).
>>>
>>> Has anyone run into this problem and come up with a solution? Is this a
>>> known bug? Is there anything I can do to fix it?
>>>
>>> Thanks very much,
>>>
>>>
>>>
>>>
>>>
>