Skip to content

Add support for RTSP-over-SSL (RTSPS)#78

Open
abigagli wants to merge 2 commits into
scottlamb:mainfrom
abigagli:support_rtsps
Open

Add support for RTSP-over-SSL (RTSPS)#78
abigagli wants to merge 2 commits into
scottlamb:mainfrom
abigagli:support_rtsps

Conversation

@abigagli

Copy link
Copy Markdown

I'm playing with some cameras that only do Secure RTSP (RTSPS) so I tried to adapt retina to support it.
I'm not sure you'll want to merge this in, because frankly:

  1. I'm not a Rust expert: there might be a better way than just hiding the difference between the TCP/TLS streams behind an enum, but I couldn't find an easy type-erasure mechanism and I didn't want to make this change bubble-up too much in the client code, so I've encapsulated it in the original tokio::Connection struct at the price of having to do quite a bit of pattern matching in the implementation of Stream and Sink
  2. I couldn't find the time to add proper testing, although the original tests are all running fine (i.e. I don't think I broke anything) and this now actually works with RSTPS streams...

@scottlamb

Copy link
Copy Markdown
Owner

Thank you for the contribution!

I'm not sure you'll want to merge this in, because...

I'm happy to give guidance on those things if you can take the time to work through it.

Before I get into the details, I'm assuming you've used this only with Transport::Tcp? I haven't played with rtsps before but my understanding is that it implies UDP communication is encrypted via SRTP, and I don't see any of that now. I think for now it'd be fine to return an unsupported error on the combination of rtsp and Transport::Udp. The current behavior (trying unencrypted UDP if the user requested encryption) seems sketchy/wrong.

@abigagli

Copy link
Copy Markdown
Author

Yep, I'd like to get any guidance and improve, just keep in mind this is a side project for me and I'm not sure how much time I'll be able to allocate.
That said, yes I completely disregarded UDP and I'm not even sure how is that supposed to work (my use case is only TCP at the moment, so that's what I focused on) but I agree that a better approach is to just refuse to work in case the user chooses rstps and udp.
I'll update the PR with this approach as soon as I can

@abigagli

Copy link
Copy Markdown
Author

Ok, I've gated the use of RTSPS so that any attempt to use it with UDP will generate an error. I've done it in the Session::setup method as it was the earliest point where both the url and the transport options were present together to avoid having to remember to check it in every client when processing command line arguments.

@scottlamb scottlamb left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My apologies for just leaving this hanging for such a long time. Got buried in a pile of mail, and I haven't been active on my open source projects to notice it more proactively. I don't mean to ignore things, and feel free to remind me if I do...

I added some comments.

Would it also be possible to add a test?

Comment thread Cargo.toml
tokio = { version = "1.11.0", features = ["macros", "net", "rt", "time"] }
tokio-util = { version = "0.7.3", features = ["codec"] }
url = "2.2.1"
tokio-rustls = "0"

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you make the new deps optional? I'd like to keep it minimal when folks don't want tls.

async fn run() -> Result<(), Error> {
let opts = Opts::parse();

// Try to get credentials

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Can we do one logical change per commit?
  • Does this work? iirc there's checking later on that explicitly errors out if the URL has credentials. I'd like to be able to just log the URL without worrying about putting sensitive stuff in the logs/tracing output, so we'd need to strip it out before passing the url along.

Comment thread src/client/mod.rs
}),
};

//AB: This is a hack to work around some devices returning the realm attribute without a terminating double-quote

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we do this in the http-auth crate instead?

Comment thread src/tokio.rs
let stream = match (use_tls, &host) {
//Domain supported in both tls and non-tls case
(_, Host::Domain(h)) => TcpStream::connect((*h, port)).await,
//Numeric IP only supported in non-tls case

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might not be necessary—I think rustls supports ip addresses now. The caveat is that I'm not sure how validation works. Some callers may just want an option to turn validation completely off anyway, treating TLS more as a thing that some cameras may require rather than a real security measure...

rustls/rustls#184

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants