Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using an SSL certificate emitted by an authority should be much simpler in Dart #20967

Closed
DartBot opened this issue Sep 16, 2014 · 18 comments
Closed
Assignees
Labels
area-core-library SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries. library-io

Comments

@DartBot
Copy link

DartBot commented Sep 16, 2014

This issue was originally filed by @Emasoft


PROBLEM: Using an SSL certificate emitted by an authority is TOO complex in Dart. Many struggle and fail to do it. Read for example:
http://stackoverflow.com/questions/25873528/dart-use-ssl-emitted-by-an-authority
http://stackoverflow.com/questions/21685205/how-does-darts-bindsecure-function-find-ssl-certificates
http://stackoverflow.com/questions/25388750/dart-https-request-with-ssl-certificate-please
http://stackoverflow.com/questions/24048258/dart-http-server-and-importing-a-ssl-certificate

SOLUTION: Dart should support SSL certificate management natively, simplifying and automating it. To do this the following improvements are needed:
1 - Eliminate the need of external utilities (certutil, openssl,... etc.) implementing their basic functionalities in the Dart framework. External utilities are often untested and full of vulnerabilities (see the openssl disaster for example). Only a google certified and tested library can be fully trusted.
2 - Provide a single Dart function with few parameters for installing an SSL certificate provided by an authority, and a single Dart function for using it. One line of Dart code should be all it takes to do both operations.
3 - Provide a simple SSL configuration class for additional, non standard SSL options (expiration, revocation, handshake, strict transport security, signature algorithm and key sizes, subdomain certificates, allowed protocols, allowed cipher suites, forward secrecy, SNI, etc.).
4 - Provide a simple client class for testing and verifying SSL certificates and HTTPS connections (expiration, revocation, handshake, strict transport security, signature algorithm and key sizes, subdomain certificates, allowed protocols, allowed cipher suites, forward secrecy, SNI, etc.)
5 - Provide a function in the ssl configuration class to save and load configuration options in a portable and human readable external json file.
6 - Extensive debugging, testing and strict code validation protocols should be done on the library before each new release to ensure high security and lack of vulnerabilities.

@iposva-google
Copy link
Contributor

Added Library-IO, Area-Library, Security, Triaged labels.

@sgjesse
Copy link
Contributor

sgjesse commented Sep 19, 2014

Removed Security label.

@DartBot
Copy link
Author

DartBot commented Sep 26, 2014

This comment was originally written by @Emasoft


Other troubles with Dart and SSL certificates:
http://stackoverflow.com/questions/26067511/accepting-any-ssl-certificate-causes-my-program-to-hang

Such an important component for a web framework like Dart cannot be neglected any more. Please hire more programmers and security experts to create a new team dedicated only to make a secure, reliable and complete HTTPS library for Dart with the features described above. Such library would be the backbone of any server side Dart application, and deserves the maximum committment from Google.

@sgjesse
Copy link
Contributor

sgjesse commented Sep 29, 2014

The SSL/TLS library used for standalone Dart is currently NSS from Mozilla (https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS). This is what is used by Chrome and based on that the Dart team selected NSS as well.

We might re-evaluate and move to OpenSSL/BoringSSL as Chrome moves in that direction.

@DartBot
Copy link
Author

DartBot commented Sep 29, 2014

This comment was originally written by @Emasoft


Projects like OpenSSL are full of bugs and insecure, as the recent Heartbleed disaster proved.
Google should write its own SSL/TLS library for Dart, exactly like Microsoft did for C# and Oracle did for Java. Please show us that Google is really committed to Dart as a development platform hiring full time security experts to develop the security part of Dart, and not just recycling some existing and buggy open source projects to skimp on development costs. We need Google to provide Dart developers a strong, fully bounds-checked library for all x509 secure protocols, with a codebase they can trust because there are higly skilled people paid to check and fix it full time. Dart is a web language more than C# and Java are. If Google is not taking it seriously enough to make it's own SSL/TLS library, then why should we?

@DartBot
Copy link
Author

DartBot commented Sep 29, 2014

This comment was originally written by @Emasoft


Also, there is a huge problem with USABILITY with the current Dart https stack (just look at the piling stackoverflow issues about that), and the Dart team should address this also with a new integrated framework. We need a better designed API for managing certificates and secure connections, one that doesn't rely on third party non-dart libraries.

@sgjesse
Copy link
Contributor

sgjesse commented Sep 30, 2014

Making a clean-room implementation of SSL/TLS for Dart is not an option we are considering. Even though there are bugs in existing implementations they are still way more stable and correct that a new implementation will be.

I agree that the tooling we are depending on as we are using NSS (mainly certutil) are not that user friendly tools. However the answers on stackowerflow should help there.

We have considered adding certificate management functions to the Dart API. However, as NSS is global for the whole Dart process - that is all isolates - we decided against it. Having one isolate change e.g. the root CAs for all isolates can introduce a security risk.

Google is participating actively in both the NSS and OpenSSL project.

@DartBot
Copy link
Author

DartBot commented Sep 30, 2014

This comment was originally written by @Fox32


For everyone that has problems getting it setup using the answers on StackOverflow, I found this blog post very helpful: http://jamesslocum.com/post/70003236123

@DartBot
Copy link
Author

DartBot commented Sep 30, 2014

This comment was originally written by @Emasoft


@sgjesse: With this decision Dart is going to lose a lot of developers. But it seems that Google doesn't care about that for quite a while now.

@whesse
Copy link
Member

whesse commented Jun 1, 2015

We agree with the points made in this bug report, and are moving Dart from using the NSS secure networking library to using BoringSSL, Google's fork of OpenSSL that is being used in Chrome and other Google products. BoringSSL is simplified and checked by Google, with some old and unneeded parts of OpenSSL removed, so it as secure a library as Google can make.

The certificate management in BoringSSL is much easier than in NSS, using certificates and keys in .PEM files (base64-endoded DEM ASN1 X509 certificates), and we will expose the SecurityContext object, where trusted certificates, keys, and certificate chains are loaded by methods on SecurityContext.


Set owner to @whesse.
Removed Priority-Unassigned label.
Added Priority-Medium, Started labels.

@DartBot
Copy link
Author

DartBot commented Jun 2, 2015

This comment was originally written by warren.strang...@gmail.com


What are the implications of this move? Will the underlying crypto functions be exposed so that they can be used for other purposes (for example, signing JWT tokens?)

@whesse
Copy link
Member

whesse commented Jun 2, 2015

We are also working on a crypto library that will support basic crypto operations, and be implemented optimally on each platform. Actually signing something would be an advanced API - I would think that for now, signing things by running a command-line subprocess from Dart, using tools from OpenSSL or another library, is the most stable solution. The obstacle to exposing all of the functions is just the size of the API, the amount of implementation, and how it would make the API more complex than most users need.

@DartBot
Copy link
Author

DartBot commented Jun 2, 2015

This comment was originally written by @jonaskello


Where is the work on the crypto library taking place? Is it public so we can view the progress?

I have ported a library for JWT signing from Java to Dart but cannot get it working because there is no package that has a working way to generate RSA key pairs in Dart. Initially I thought the cipher package could do this but it did not work in practice. I think it would be really nice if the mentioned crypto library could provide this function. The ported library is here:

https://github.com/jonaskello/jose_jwt/tree/develop

@whesse
Copy link
Member

whesse commented Jun 3, 2015

cc @sgjesse.

@DartBot DartBot added Type-Defect library-io area-core-library SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries. labels Jun 3, 2015
@jonaskello
Copy link
Contributor

I received a comment about shelf_auth and googleapis_auth but maybe it was lost when this moved to github. Anyway, those packages only solve specific use cases or flows and does not provide a full implementation. The way I see it, to bring full OAuth2 or OpenID Connect support to Dart we need to solve it in this order:

Crypto > JWT/JOSE > OAuth2 > OpenID Connect.

Having a good crypto package would enable the other packages. The cipher package is closest to this today but it cannot be fully enabled becuase there is no SecureRandom API in Dart. There is also some more discussion about this here:

https://bitbucket.org/andersmholmgren/shelf_oauth/issue/1/provide-an-example

https://plus.google.com/u/0/+JonasKello1/posts/bHA1rnURNsv

If at least a SecureRandom was provided in Dart I think the rest could be solved in packages.

@ricowind
Copy link
Contributor

ricowind commented Jun 4, 2015

@jonaskello yes it was "lost" (I am manually updating the 5 issues), here is the text for completeness:
@jonas.kello isn't this already used in packages like shelf_auth or googleapis_auth?

@whesse
Copy link
Member

whesse commented Sep 2, 2015

The change to BoringSSL has landed in the dev channel, in version 1.13.0-dev.0.0. It will be on the stable channel when stable version 1.13.0 is released. The other requests and points in this comment are still important, so leaving the issue open.

@whesse
Copy link
Member

whesse commented Oct 5, 2015

Closing this issue, because SecureSocket has migrated to BoringSSL, with an easier certificate interface, exposing the SecurityContext object for certificate management. All the work on a cryptographically secure RNG should be discussed in issue #1746

@whesse whesse closed this as completed Oct 5, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-core-library SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries. library-io
Projects
None yet
Development

No branches or pull requests

6 participants