add an example tls server with provider #1440
Conversation
Codecov Report
@@ Coverage Diff @@
## jbp-generalise-crypto-usage-pt3 #1440 +/- ##
================================================================
Coverage 96.46% 96.46%
================================================================
Files 72 72
Lines 15179 15179
================================================================
Hits 14642 14642
Misses 537 537 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
|
@ctz should I split the code for the example provider instead? |
|
Thanks for the server example, we can integrate this after the parent branch is merged. For the rest, I think it is unlikely we'll release a crate from this demonstration-level code, and making it fully-featured will occlude the goal of it. I think a project like rustls-on-rust-crypto-crates probably does deserves its own repo and testing infrastructure, though if the aim for parity with ring and ring-alike crates the testing could be based on those established here. |
|
@ctz Sure. I will likely fork the new provider code out, but may I know what software license of that provider code is? I would like to make a repo for those code myself as you suggested but some of the code is yours, so I need to ask for permission first. |
Using the crate without this feature means something external needs to provide all the cryptography, and (eg) convenient integrated key loading APIs disappear.
…used The prior arrangements are still available (and the default), if the crate is built with the *ring* feature. `WebPkiSupportedAlgorithms` is a new structure (designed for static construction, and direct use in webpki calls) that links `webpki::SignatureVerificationAlgorithm`s to their corresponding TLS `SignatureScheme`. This replaces the hardcoded mappings in `fn convert_scheme` etc.
If this is compiled out, naturally a bunch of public API and testing code falls away.
This is an example that builds a mostly-unchanged rustls example (simpleclient), but only using crypto from the rust-crypto project and elsewhere. This is intended to be minimalistic, and not a complete replacement for *ring*. It implements: - TLS1.3 TLS13_CHACHA20_POLY1305_SHA256 cipher suite. - TLS1.2 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 cipher suite. - X25519 key exchange. - RSA-PSS-SHA256 and RSA-PKCS1-SHA256 signature verification for verifying the server, integrated into the webpki crate. - random generation using `rand_core`. This means it can fetch www.rust-lang.org. TLS1.2 is not strictly necessary for this server, but serves to demonstrate that part of the API.
ctz
force-pushed
the
jbp-generalise-crypto-usage-pt3
branch
from
38a471d
to
e9d88fe
Compare
stevefan1999-personal
force-pushed
the
jbp-generalise-crypto-usage-pt3
branch
from
8118450
to
563b7ba
Compare
If this is compiled out, naturally a bunch of public API and testing code falls away.
This is an example that builds a mostly-unchanged rustls example (simpleclient), but only using crypto from the rust-crypto project and elsewhere. This is intended to be minimalistic, and not a complete replacement for *ring*. It implements: - TLS1.3 TLS13_CHACHA20_POLY1305_SHA256 cipher suite. - TLS1.2 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 cipher suite. - X25519 key exchange. - RSA-PSS-SHA256 and RSA-PKCS1-SHA256 signature verification for verifying the server, integrated into the webpki crate. - random generation using `rand_core`. This means it can fetch www.rust-lang.org. TLS1.2 is not strictly necessary for this server, but serves to demonstrate that part of the API.
|
I force pushed the changes and only included the necessary change to add the example server The old provider code is still available at stevefan1999-personal/rustls at patch-add-more-provider (github.com) but I will split them by making a new crate that points to the rustls git repo with the ring-optional branch. |
ctz
force-pushed
the
jbp-generalise-crypto-usage-pt3
branch
from
e9d88fe
to
76a2a07
Compare
…3' into jbp-generalise-crypto-usage-pt3
I converted this to a draft while we're waiting on another branch to make it easier to scan the PR list and get a sense of which PRs should be prioritized for review. |
ctz
force-pushed
the
jbp-generalise-crypto-usage-pt3
branch
9 times, most recently
from
3144ff2
to
ba26a6d
Compare
|
@ctz I also forked the content of this PR out to its independent repo: stevefan1999-personal/rustls-provider-rustcrypto (github.com) Feel free to contribute. |
ctz
force-pushed
the
jbp-generalise-crypto-usage-pt3
branch
2 times, most recently
from
937bb0c
to
78295cf
Compare
This provides an example server using the crypto provider with some code referenced from internal examples. This is a very bare-bone example with some of the unnecessary features such as CRL removed. It is also assumed to use PKCS_ECDSA_P256_SHA256 for key signing at the moment (due to the config in rcgen uses this).
Use
curl https://<your IP address>:4443 --insecure -vto view SSL status with curl.Use
openssl s_client -connect <your IP address>:4443to debug SSL.Only ECDSA keys and certs is available since rcgen depends on ring, but ring cannot generate RSA keys and certs yet. There is also an ongoing problem with ring regarding ed25519 support, that the PKCS#8 DER it generated is not standard-compliant: briansmith/ring#1518, so ed25519 test is not included,