arvidn
SSL torrent and url seeds
libtorrent version (or branch): 2.0.9
platform/architecture: macOS, arm64
compiler and compiler version: clang
The is not strictly-speaking an issue but something I found it. I have been carefully reading on https://github.com/arvidn/libtorrent/issues/3892 and https://github.com/arvidn/libtorrent/issues/6410. I was already trying to do the same. The thing is that you do not necessarily have the same CA for a http seed (especially when stored on a CDN) and in the private network for your peers. @arvidn , as you mentioned the problem lies with the CA cert that we put in the SSL torrent. So basically for it to work, I need the SSL context to have 2 CA in its store and not only 1. It turns out, there is a relatively easy solution without patching lib torrent. I the attached example, you can see the code and the associated torrent. It is an SSL torrent that has specific CA for the peer certs to check. And when I add the torrent to my session, I make sure I get the store and add the one for the http download (using Amazon S3 there).
I was wondering if the set_trust_certificate function is ssl.cpp should not simply be able to load multiple certificates from this piece of data. If you agree, I could provide a patch for lib torrent for this. It requires no change to the API and it would be backward compatible.
HTH
sorry for the delay. I would be open to exposing an "official" way of adding certificates to the cert store.
I think it would make sense to keep it simple. I would think you could get away with a single member function on torrent_handle (and torrent under the hood).
Hello @arvidn and thank you for the reply. I was actually thinking that the current way to handle cert(s) could be enough and it would just require a change in the doc and make sure that we can load more than 1 url. I have changed topic in the meantime but if I get a chance I will try to come up with a patch we could discuss.
Whatever you get back from native_handle() is not intended to have a stable API (nor ABI)
In your use case, you're adding a certificate to authenticate the web server, but is the web server also validating your client certificates? It seems odd to use SSL torrents (where all peers authenticate to each other) while the content is openly available over HTTPS (without client certificates). But maybe you do require client certs for the HTTPS access as well.
well s3 (yes this is for s3), does not allow this but then I am only adding the url seed manually and that one is a presigned url that I manage fully. Not ideal in the general case but it just works for me.