Allow to import existing certificate

[ibsusu]

In-browser, RTCPeerConnection provides an option to generate RTCCertificate or can generate it by itself.
https://w3c.github.io/webrtc-pc/#dom-rtcpeerconnection-generatecertificate

It would be helpful to allow it to import existing certificates, for instance when we want to use the same certificate for communication with signalling server.

Generator with such functionality(FromPEM) is already implemented in Chromium code:
https://github.com/chromium/chromium/blob/0aee4434a4dba42a42abaea9bfbc0cd196a63bc1/content/renderer/media/webrtc/rtc_certificate_generator.h

This was previously discussed here:
#1853

I believe that this was the wrong decision and makes browsers second class citizens when considering torrenting or distributed file transfer in the browser. Allowing users to connect directly to peers that they've connected to in the past without the round trip negotiation dance would be incredibly useful. Torrenting already comes with mechanisms to make sure that the files transferred are correct (hashing) and mechanisms to ban bad users, irrespective of the cert used to connect.

This should be allowed as it smooths out the reconnect process when we know where we're connecting. Add it in as a privileged api method, please. Pretty please.

[lgrahl]

I understand that this can be helpful but it would not help the torrent use case which is your rationale. Let me explain:

Allowing users to connect directly to peers that they've connected to in the past without the round trip negotiation dance would be incredibly useful.

This is not being fixed by allowing to reuse a certificate. It requires much more than that, see w3c/webrtc-nv-use-cases#15 (comment)

[ibsusu]

My aim was to make a new session with the stored cert and then sending the required information to the torrenting peer when we've already stored the rest of the information necessary to contact them. With regard to torrenting these certs are superfluous. All of the files are hashed, the pieces are hashed and the peer's ip address, port and peer id are what is used to determine whether to ignore, ban, or put them on probation. We can pass certs around with reckless abandon and not give a hoot. Encrypting in userspace works fine as well if we need to care about it. But right now to get around this stupid handshake problem I have to pass around natively created certs to other native peers so they can just negotiate for the peer that a browser wants to connect to.

If the browser could do this as well via an extension then we get a lot more play for design.

Does this not make sense? Have I forgotten some detail?

[lgrahl]

IIRC you want to circumvent signalling. But there are more variables than the certificate's fingerprint in the signalling data. ICE username fragment, ICE password, ICE candidates, ... none of this is persistent, nor does it allow you to use it for more than one 1-to-1 connection.

It's potentially a different story for browser-to-native communication with a couple of hacks.

[ibsusu]

Let's theorycraft for a bit: 4 users have public & private certs, ice username fragments, passwords, candidates.

user 1 connects the normal, handshake way to user 2 and then sends all of his info to user 2.
user 3 connects the normal handshake way to user 2 and then sends all of her info to user 2. User 2 says he knows user 1.
user 3 wants to connect to user 1 and starts the negotiation process with user 2. User 2 uses everything received from user 1 then sends the sends the final connection information like the chosen candidate and whatever to user 1 to let them know user 3 is going to try to connect.
user 3 connects to user 1 and gets all of his information as well.
user 4 connects to user 3 normally and says they also want to connect to user 1. Repeat.

so to reiterate:

user 1 -> user 2
user 3 -> user 2
user 3 -> user 2(1's creds) -> user 1
user 4 -> user 3
user 4 -> user 3(1's creds) -> user 1

I believe this is doable for native->native and brower->native connection attempts but not native->browser or browser->browser connection attempts. Every connection is still one to one but we skip half of the relay and allow for a much quicker PEX lookup and dht process. To be perfectly honest I wanted to go one step further and have a user sign for the remote user of the connection themselves locally and just try to connect with a single signal call.

I don't know if this qualifies as a hack but It seems fairly straight forward. As for not being persistent, that's fine. We can remove them. I doubt they change often enough to make this technique useless.

[lgrahl]

1 can't connect to 3 with the same ICE candidates it is connected to 2. There is currently no way to establish multiple connections over a single RTCPeerConnection instance.

[ibsusu]

That goes for browser->native and browser->browser right? What about the inverse?

[lgrahl]

Everything deviating from the spec can do whatever it wants. It may be possible to multiplex connections over the same ICE credentials and candidates (dunno, haven't tried but I presume it's going to be very hacky). A native implementation can also choose to just accept any certificate, so what certificate the other peer uses would be irrelevant.

[ibsusu]

@lgrahl First off, thank you again for setting me straight on the capabilities of all of this. Second, I just have to say that the entire ssl security mechanism behind the web today is really hindering us from doing some amazing things.

I'm just going to close this. The request leads to a dead end.

[lgrahl]

Second, I just have to say that the entire ssl security mechanism behind the web today is really hindering us from doing some amazing things.

I heavily disagree with that. I've clearly pointed out that a native implementation can just accept any certificate and pin its own, so at least that portion would not require any individual signalling. You would still have to sort out all the other variables to establish an unsignalled connection (which is possible I believe). But that would be limited to browser <-> native. And there are most likely pitfalls.