Comments (41)
Some plans for this, but have been waiting for DTLS1.3. That is nearing completion now.
from rustls.
@ctz We'd like to sponsor DTLS for rustls including maintenance. @djc would be willing to help us implement it, but first we'd like to coordinate with you which version of DTLS (1.2/1.3) would be accepted for upstream and some implementation details too. How can we get in contact?
from rustls.
It would be great to see DTLS support, is there any progress?
from rustls.
A pure-rust DTLS implementation would be fantastic for embedded usecases. Any further updates on this?
from rustls.
Would really love to see DTLS implemented in Rustls. We need it for some WebRTC work and currently are forced to use OpenSSL.
from rustls.
Just off-hand, I'd highly recommend not trying to wrap a UdpSocket
, but instead exposing methods to consume/write out datagrams. That will make testing simpler and less fragile, and make the interface more broadly applicable.
from rustls.
Any additional thoughts or updates on this? Something we've been interested in as well and investigating options for, cc @luna-duclos
from rustls.
DTLS 1.3 looks like it is nearing completion, currently in the RFC editor's queue.
Meanwhile, for some use cases maybe QUIC + its datagram extension is a decent fit?
(If someone is interested in sponsoring DTLS 1.3 support, I'd be happy to connect.)
from rustls.
Agreed with @Ralith, would be nice to mimic the rustls API where possible. I might try reviewing your work as you go, if you want to tag me in PRs or something.
from rustls.
Feel free to hit me up on Matrix or Twitter. On Matrix I'm @djc:mozilla.org I think.
from rustls.
No plans at the minute. I know it's used for some VPNs, webrtc and some iot things. What is your use case?
from rustls.
VPN ^^
from rustls.
Would you see DTLS within the scope of this library (i.e. would you accept pull request)?
from rustls.
I am currently playing around implementing DTLS. Would it be the best to do this on the tls13 branch?
from rustls.
Would you see DTLS within the scope of this library
Perhaps. I'm not sure some of the external APIs are really suitable, to the extent that it might make sense as a separate crate built from the same codebase.
Would it be the best to do this on the tls13 branch?
Yes. Though beware that this branch is still in major churn and is overdue a serious refactoring of server_hs.rs
/client_hs.rs
from rustls.
In case you are interested: https://github.com/manuels/rustls/tree/dtls12
(although I just implemented Payload data structures and parsers up until now)
- Payload data structures and parsers
- Deframer
- Handshake Fragmenter
- Handshake De-Fragmenter
- Protocol logic
from rustls.
Looking good! 👍
from rustls.
Ok, I figured out that the situation is a bit complex, and there are several ways to implement DTLS specific stuff. Since this decision can have quite an extensive impact on the codebase I'd like to discuss how to proceed.
The Problem
DTLS requires some additional fields in Message
and HandshakeMessagePayload
and ClientHelloPayload
as well as an additional handshake message HelloVerifyRequest
. Additionally handshakes can be fragmented on the handshake protocol level instead of the record layer level.
See the sketch where modifications are highlighted.
Possible Solutions
Option
s
The additional fields could be integrated as Option
s into the regular TLS data types and would just be ignored in the TLS implementation. E.g.
pub struct ClientHelloPayload {
pub client_version: ProtocolVersion,
pub random: Random,
pub session_id: SessionID,
pub cookie: Option<Cookie>, // <-- !!!
pub cipher_suites: Vec<CipherSuite>,
pub compression_methods: Vec<Compression>,
pub extensions: Vec<ClientExtension>,
}
Traits
A TLS Message
and a DTLS Message
are quite similar and the overlapping code could be moved into a trait MessageTrait
. This would probably be the most rusty solution, but it would also make the code a bit more complex if most functions have a generic argument type of MessageTrait
.
Macros
If you want a TLS Message
and a DTLS Message
data type in the codebase the overlapping code could probably also be deduplicated by some macro magic. But again, it might make the codebase more complex if there are macros scattered everywhere.
Maybe you guys can up with a better idea. I would love to get some feedback to see how to continue with implementing DTLS!
from rustls.
After some time thinking about it, I think it's worth renaming the current Message
to TLSMessage
and creating a Message
trait that is implemented by by TLSMessage
and a DTLSMessage
.
Then all struct impl
s just need to be impl<Msg: Message+Codec> MyStruct
. Any comments on this?
from rustls.
DTLS/TLSMessage sounds ok, but beware that some performance relies on Message being moved by value into the processing functions: so the traits will need to cover these cases by exposing (eg) take_payload
.
sorry, i overlooked your earlier comment.
for ClientHelloPayload
and the like, are the functions which process these likely to be mostly shared between TLS and DTLS? if they're vastly different, then having a ClientHelloPayloadDTLS subtype would suffice (like some of the TLS1.3 types). otherwise, optional elements would be ok.
from rustls.
for ClientHelloPayload and the like, are the functions which process these likely to be mostly shared between TLS and DTLS?
They are basically the same. The DTLS version of ClientHelloPayload just adds an optional cookie.
from rustls.
Hey @ctz, I've seen in your TODO project that you are refactoring the state machine.
Do you already have some WIP that you could push to a new branch to github, so I can see where this is going.
I am at the point that I'd have to adapt it to implement DTLS.
Would be great!
Thanks!
from rustls.
I don't have any wip branch for that yet. But I'll push one once I do and link it here.
from rustls.
In case this is useful: I tried to summarize the TLS state machine a while a go: https://github.com/manuels/tls-state-machine
from rustls.
A quick update. I had to refactor the TLS specific code of SessionCommon
into a StreamTransport
struct. I will now proceed and implement a DatagramTransport
struct with a similar but DTLS specific behaviour.
from rustls.
I am wondering how the user should decide which protocol to use.
Either the instantiation of {Client,Server}Session
takes a Trait parameter ala ClientSession<TLS>
(or ClientSession<DTLS>
) at compile time, or it will decided at runtime using the ProtocolVersion.
But right now I do not see, how to implement this without a lot of ClientSessionImpl
-> ClientSessionImpl<M:Message>
renaming in the code.
@ctz, do you have a comment on this?
from rustls.
How about separate DatagramClientSession
/DatagramServerSession
types? I'm assuming these types need some kind of extra methods for timed triggering of retransmits?
On the question of ClientSessionImpl
, could we inject implementations of a trait that deals with the important differences between datagram/stream TLS? Like which type of message to use. Actually those traits could be quite big. Hm.
from rustls.
Just wondering if there has been any progress on this issue, I'm working on IoT and support for DTLS would be very handy.
from rustls.
Wireguard solved my problems so far and I do not have time to work on DTLS currently.
Maybe that might change in a year's time or so...
from rustls.
@manuels Do you have time to have a look at it now? I would love to see some progress on this implementation. Many IoT platforms need communication over DTLS for security. I would love to work on this, but this is way over my head.
from rustls.
A DTLS implementation would be very awesome, I hope you find some time @manuels, seems like you were very close!
from rustls.
I recently discovered https://github.com/webrtc-rs/dtls but I don't know whether it is already usable.
from rustls.
Also since QUIC has progressed very well, which runs over UDP but uses TLS building blocks from the regular TCP TLS implementations, the requirement for DTLS (UDP) has ... well, diminished.
from rustls.
I recently discovered https://github.com/webrtc-rs/dtls but I don't know whether it is already usable.
Unfortunately, that crate seems to be very tightly fused to std.
from rustls.
I recently discovered https://github.com/webrtc-rs/dtls but I don't know whether it is already usable.
There are is a e2e test PR that shows it in action, but there seem to be a few structs that are missing. Not sure what is happening there.
from rustls.
Folks, it's useful to have a link to that crate here but further discussion about it seems off-topic for this issue.
from rustls.
My feeling is that DTLS would need a totally different public API to rustls, to the extent that it doesn't really make sense to have it in the same crate (even as a cargo feature). What I would be open to is refactoring the core crate to allow reuse of the parts common between TLS/DTLS,. What I would never want to see in the core crate is stuff like https://github.com/openssl/openssl/blob/54b40531307fcaba1206e98f4cae73f0532fbdbb/ssl/record/ssl3_buffer.c#L45-L48 -- that would seem to me to be evidence of bad architecture.
As for actually making progress on this, the tlswg continue to alter the design, and I'm not sure writing a DTLS1.2-only implementation is a sensible idea at this point.
The other thing I'm aware of is that DTLS and embedded use cases often come hand-in-hand, so the DTLS crate would likely have to pay more attention to the constraints this brings.
from rustls.
While playing around with DTLS, I came to the conclusion that TLS and DTLS are working with two entirely different kinds of streams, and that knowledge about MTU, framing, and other items are important to a consuming DTLS (de)encryptor.
Thus, I concur this has to be a different API/crate, if it means it could consume a std UdpSocket
, and correctly abstract it's framed send
and recv
over it.
from rustls.
For anyone curious about this development; i'm going to attempt to create an own implementation of this, as per ruma/lb#7, taking https://github.com/pion/dtls and this library as inspiration, at https://github.com/shadowjonathan/dustls
I know i'll be making mistakes, so i'm inviting people who are interested in this to help me out as well.
If there are any rustls maintainers reading this; Collaboration is appreciated, once/if i get the implementation up and close to something usable, i'm offering the repo to be adopted by the rustls org, including crates.io ownership and all.
I'll need recommendations on supported cipher suites, though for now it is a goal to be compatible with at least some of these cipher suites.
I'll initially be executing a rough API design as described here, though obviously it's open for discussion. This is going to be v1.2-only for the moment, providing a base implementation, until v1.3 is finalised, after which i'll take a look and consider how the library's API would have to be changed in order to accommodate it (if that'd be required).
Efforts are going to be here, though with me doing this in my free time, commits are going to be sporadic, help is appreciated.
from rustls.
One of my goals is definitely to be as agnostic as possible to the underlying transport(s), only that they have to receive/send their IO in a framed fashion, and that hints like (P)MTU can be passed through.
would be nice to mimic the rustls API where possible.
From the rough API draft, "DTLSSessionMachine
" already looks quite similar to ConnectionCommon
, though i'll have to think through and study the rustls
api surface before i can commit to what i'm thinking right now, but i'll definitely be trying to match a similar interface.
from rustls.
@djc @ctz I'd like to collaborate a bit more closely on this (especially with the idea of such a core crate), so i can quickly ask some questions in the future, do y'all have any preferred IM handle i can contact you with? I'd personally prefer matrix: @jboi:jboi.nl
, but my twitter DMs are also open as a point-of-contact.
from rustls.
Related Issues (20)
- discussion: re-exporting rustls-pki-types HOT 5
- P-521 with aws-lc-rs
- ShangMi (SM) Cipher Suites HOT 1
- Revisit benchmarks in the repository HOT 2
- Certificate without SNI HOT 4
- Experimental support for X25519Kyber768Draft00 HOT 2
- ERR_INVALID_HTTP_RESPONSE HOT 9
- v0.22 breaks backward compatibility HOT 3
- mtls doesn't prompt browser for certificate HOT 7
- how to upgrade to v0.22 in this code? HOT 12
- PrivateKeyDer support for pkcs11 / ccid HOT 3
- Client handshake succeeds in TLS 1.3 even though the server has rejected the certificate HOT 7
- Internal buffer size question and related issue HOT 1
- Can someone explain what this library is for? HOT 13
- `get_sni_extension` is no longer public which breaks our application HOT 6
- Support jemalloc for benchmarks
- reduce bifurcation of library internals by using low-level API in high-level API HOT 8
- About empty root hints list in "certificate_authorities" extension HOT 5
- Noticeable performance degradation from 0.21 to 0.22 HOT 2
- How can I explicitly disable TLS 1.3 in the config builder API and/or improve logging? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rustls.