>>1269
I had heard that EFF were involved in that, but I forgot the name–thank you for reminding me.
Now, I'll reiterate that I know very little about this, but doesn't regular cert verification require a static web address? Normal https will verify based on DNS domain name, which means it won't work for a p2p network where servers/supernodes only have non-static IPs. i.e. https://[ip address]/muh_request is always invalid.
I assume it means you have to either:
Throw up a clientside dialog, like how FileZilla does with FTP over TLS, that says "Hey this server has this cert, does this sound ok?" and then remember that cert in future.
Have a different verification scheme with a custom hydrus authentication service, where instead of asking about example.com, we say "Hey, authentication server, does [unique server id] have [public certificate id]?"
Say 'screw it' and automatically accept all certs clientside, which I imagine makes you vulnerable to man-in-the-middle attacks or whatever and may well destroy the whole house of cards.
Or something else. (likely using a different protocol)
I am not sure how much you can screw around with the https libraries in python, and indeed if doing so is a terrible idea. If I remember right, some of them don't even do verification, so this whole question might be moot. If I can interact with the library's cert cache, then I can throw up a dialog or write my own verification schema. Still, I suspect https is just something p2p networks shouldn't try, and instead I should be looking at something else, like this:
https://twistedmatrix.com/documents/current/api/twisted.protocols.amp.html
Which I have played with a bit and had small success with. Again, I think I need to put some time aside and read through some other project's source code.