SDP Use and Security Clarifications

This is really cool.
If I understand the sdp key exchange, it would be possible for a service to gen a key as a QR code and the developer to scan it and save it to a secure location on their laptop.
Then the service can be deployed somewhere with the public key.
Then when you want to connect to that server you just use the QR code, decrypt it to text and connect.

Please let me know if that's a reasonable thing based on how sdp and this software works
I can then make a little demo and PR it if you want

[maxmcd]

The SDP describes how your webrtc session can be connected to.

If I generate one from my computer right now it contains this section:

a=candidate:udpcandidate 1 udp 4386 192.168.1.22 52104 typ host generation 0
a=candidate:udpcandidate 2 udp 29006 192.168.1.22 52104 typ host generation 0
a=candidate:udpcandidate 1 udp 57356 257.141.200.35 58755 typ srflx raddr 192.168.1.22 rport 58755 generation 0
a=candidate:udpcandidate 2 udp 28752 257.141.200.35 58755 typ srflx raddr 192.168.1.22 rport 58755 generation 0

Those are ips and ports that the webrtc lib thinks I can be accessed on. Your SDP session is only valid for a brief moment of time, a few minutes. If you change networks your ips and ports will be different, but more importantly the routers in between you and the other connecting user are only going to route packets correctly for a short while before considering the connection to be stale and closing it.

All this is new to me as well and some of the details might be wrong, but I can tell you that you should expect the SDP values to be short lived and storing them securely for re-use would not work as expected .

Very open to ideas about how to accomplish what you're describing though. Maybe api access to one of the secure messaging platforms would work. With opt-in from both parties you could arguably dial out to people by username.

hey @maxmcd thanks for response.

Me too - still learning and standing on lots of big shoulders as always :)

Your suggestion of using a Third Party is one way, but for me i would want to run it all myself and not trust anyone except Lets Encrypt and run the server myself.

Maybe the following is a good staggered approach ?

1. Get the WebServer working locally with real HTTPS, so the browser does not say its not secure.
   This is just to have a local dev environment we trust.
   This should do it and could be added and wrapped as cmd:
   https://blog.filippo.io/mkcert-valid-https-certificates-for-localhost/
   https://github.com/FiloSottile/mkcert

2. Get the WebServer running in the Cloud on gae with proper HTTPS Termination.
   gcloud app deploy

• GAE does the HTTPS for you i think.

3. Then try out the idea of a QR generator and Reader.

• There are some good golang QR generators out there.
• The idea is for the Server to display the QR code, and the User to scan it using their Mobile OR click save and save it to their laptop. In Both cases the key would be stored in the Trust Store. For First Phase just do the Laptop UseCase for quick development.
• The makeCert project has the code for interacting with ALL Desktop Trust stores.

4. Now we have the ability to run things, and can try using pre generated keys to create sessions.

• We can still also support the use case of generating keys at runtime like your system still does.

this is just an idea.... But pre generating keys seems like a pretty useful thing.

[yunfan]

@maxmcd i just met this problem too, this tool is very cool ,and i want to use it to allow me connect to any devices that under the control of mine, the only problem is the sdp key exchanging

i think the tool could add a new option to indicate the keyexchanging service, which could be implment by user themselves, a quick way is use a tls enabled pub/sub services

and although i havnt learnt go yet, (this project really made my interesting), i still know there were a library created by caddy which let you got/update cert automaticlly @ghost