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
Comments
Added Library-IO, Area-Library, Security, Triaged labels. |
Removed Security label. |
This comment was originally written by @Emasoft Other troubles with Dart and SSL certificates: 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. |
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. |
This comment was originally written by @Emasoft Projects like OpenSSL are full of bugs and insecure, as the recent Heartbleed disaster proved. |
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. |
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. |
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 |
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. |
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?) |
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. |
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: |
cc @sgjesse. |
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. |
@jonaskello yes it was "lost" (I am manually updating the 5 issues), here is the text for completeness: |
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. |
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 |
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.
The text was updated successfully, but these errors were encountered: