boringSSL dart 1.13 on Windows

[TylerThompson]

I am having issues making an http.get() request since I updated to dart 1.12. I am using Windows 10 to develop on with IntelliJ IDEA (15 EAP) as the editor. When I send a request I get the following error:

864050208:error:100be07e:SSL routines:ssl3_get_server_certificate:CERTIFICATE_VERIFY_FAILED:src\ssl\s3_clnt.c:1031:

[2015-9-10 9:52:56.021] HandshakeException: Handshake error in client (OS Error: Unknown error from BoringSSL library, errno = 0)

I have looked up the issue and only one source was found but did not fix the Problem. #24208

Can someone explain what I need to do to fix this issue?

Code:

I am getting the error when requesting the token

var requestAuthToken= await http.post('https://identity.api.rackspacecloud.com/v2.0/tokens', headers : {'Content-Type':'application/json'}, body: JSON.encode({"auth": {"RAX-KSKEY:apiKeyCredentials":{"username":"XXXXXXXX","apiKey":"XXXXXXXXXXXXX"}}}));

var authResponse = JSON.decode(requestAuthToken.body);
String token = authResponse['access']['token']['id'];

List binaryData = [11,22,44,111,333...];

var upload = new http.Request('PUT', Uri.parse('https://storage101.iad3.clouddrive.com/v1/MossoCloudFS_xxxxxxx/xxxxxxx/testimage2.jpg'));
upload.headers['X-Auth-Token'] = token;
upload.headers['Content-Type'] = 'image/jpeg';
upload.bodyBytes = binaryData;
await upload.send();

[mit-mit]

BoringSSL is not in 1.12 stable, it's a 1.13 feature. Bill, any idea what is going on?

[mit-mit]

@TylerThompson, can you clarify which build you are running? You can run dart --version in a terminal/command prompt (make sure dart is in path).

[whesse]

This could be an issue with the hostname verification on one of the two requests. You should figure out which of the two requests is failing, by commenting out the second.

Do you have to add a trusted certificate, or a client certificate, to connect to these servers? If so, you need to add it to your SecurityContext object in Dart 1.13. If it is a client certificate, you must stay on 1.12 until it is available in 1.13 (within weeks).

If I go to one of the URLs in chrome, and look at the connection information (click next to the url, where a lock would be), I get warnings that the connection is using an obsolete cipher suite, and that the certificates are signed with an outdated hashing method. It could be that we are not supporting these methods. Our choice of what encryption methods to allow is set with:
SSL_CTX_set_min_version(context, TLS1_VERSION);
SSL_CTX_set_cipher_list(context, "HIGH:MEDIUM");
SSL_CTX_set_cipher_list_tls11(context, "HIGH:MEDIUM");
and this might exclude the outdated encryption this site is trying to use.

If you just try to do an https get from https://identity.api.rackspacecloud.com/v2.0/tokens, you may get the same error. In this case, we can see if allowing more encryption methods would let the connection work, and discuss whether we should enable them in Dart. If this is the case, I would also let the site know that their security is outdated, and they should fix it.

You should be able to get your app working again by staying on stable Dart 1.12, since dev Dart 1.13 is the only one with BoringSSL on it.

[TylerThompson]

My mistake on the version, I was on 1.13 the whole time. I don't think I need a client certificate to connect these servers @whesse and I do not have one. They want you to request an Authorization token by sending your username and api key to their server. After you have the Auth token, then whichever http request you decide to do is valid. I switched back to 1.12 and the request was working again. The issue in 1.13 was the initial request to get the Auth token. Thanks for your help! :)

[jonaskello]

I'm also seeing this issue on Windows 10 (but works on Windows 8.1). Minimal repro, create minimal console app with webstorm:

main.dart:

import 'package:http/http.dart' as http;

main() async {
  // This works
  String result = await http.read("https://www.dartlang.org/");
  // This fails in Dart 1.13.0-dev.2.0 on Windows 10 but works if I load it in chrome, the error is:
  // 104457152:error:100be07e:SSL routines:ssl3_get_server_certificate:CERTIFICATE_VERIFY_FAILED:src\ssl\s3_clnt.c:1031:
  String result2 = await http.read("https://identity.api.rackspacecloud.com/v2.0/tokens");
}

pubspec.yaml:

name: dart_cert_fail_win10
version: 0.0.1
description: A simple console application.
dependencies:
  http: any

[jonaskello]

Same issue on mac. The issue may exist for Win 8.1 too, not sure anymore.

[jonaskello]

In my original code which caused this issue I was using the URL https://login.promaster.se/idsrv/.well-known/openid-configuration (but I changed it in my repro above). If I navigate to this original URL in Chrome it seems to be using TLS 1.2, AES_256_CBC, HMAC-SHA-, ECDHE_RSA. Would any of those also be outdated?

[whesse]

Yes, we have seen other errors due to outdated low-security ciphers, which
are not supported in BoringSSL. We may need to support more of these. The
case I saw before, if you went to the site in Chrome, and clicked on the
padlock, you saw warnings about the low-security ciphers used.

I will be investigating this.

On Fri, Sep 18, 2015 at 6:31 PM, Jonas Kello notifications@github.com
wrote:

In my original code which caused this issue I was using the URL
https://login.promaster.se/idsrv/.well-known/openid-configuration (but I
changed it in my repro above). If I navigate to this original URL in Chrome
it seems to be using TLS 1.2, AES_256_CBC, HMAC-SHA-, ECDHE_RSA. Would any
of those also be outdated?

—
Reply to this email directly or view it on GitHub
#24330 (comment).

William Hesse

[jonaskello]

Thanks for investigating! Yes I saw that warning too on the link in the original post. However that warning it did not appear on the link in my previous post even though it causes the same problem. Maybe a clue, or not :-).

[whesse]

Neither of these two problems are due to the cipher used. The connection to login.promaster.se failed because we did not send the hostname in the handshake, using SNI (Server Name Indication). We will add this feature immediately. The connection to identity.api.rackspacecloud.com failed because we didn't have certain flags set to allow certificate chains where we trust a certificate in the middle of the chain, but not the certificate at the root of the chain. I have a fix for this that will be committed soon.

The certificate chain problem comes from a CA with an old root certificate and a new root certificate replacing it. The new root is signed by the old root, and servers serve a chain (server certificate) -> (intermediate certificate) -> (new root) -> (old root). But our modern set of trusted root CAs includes (new root) but not (old root). This is Thawte, by the way.

[whesse]

Both these issues are now fixed on bleeding-edge. The fixes are not yet in the dev build of the SDK, which is released weekly, usually.

[jonaskello]

Thanks for fixing this :-)