On Tue, 2019-09-17 at 16:08 +0200, Daniel Stenberg wrote: > On Fri, 13 Sep 2019, David Woodhouse via curl-library wrote: > > > So: what would it take to use curl for HTTP while basically abusing it from > > both sides? Not only do I need it to use my own underlying TLS connection, > > but I also need in some cases to make a CONNECT or even GET request which > > completes as soon as it has an HTTP 101 or 200 response and immediately > > hands the connection back to me since it's passing binary traffic over it > > then. > > "my own underlying TLS connection" could probably be done by using > CURLOPT_OPENSOCKETFUNCTION, depending on how you do it. Then you can hand > over > a socket to curl to work on and you do the rest.
For that to work when all I give curl is a file descriptor, I'd need to use a socketpair and then proxy the data back and forth between it and the actual socket used for the TLS connection. Ideally for this kind of approach to work, I'd want to be able to provide 'read' and 'write' functions to curl, not just a sockfd. > If you rather curl do the socket handling and the existing TLS backends > aren't > suitable, then I figure you'd need to create a new TLS backend for this > purpose - but there's no dynamic or external way to hook one in. You'd need > to > change curl code and recompile for that. Right. Maybe the theoretically best answer is not to create a new TLS backend, but just to fix the existing ones not to offend me. Nothing I'm doing here (or at least, very little of it) is truly specific to the VPN use case. Much of it is just general principles of how SSL client applications should handle certificates, which has annoyed me so much over the years that I've written it up as http://david.woodhou.se/draft-woodhouse-cert-best-practice.html I have, on occasion, pushed curl's TLS back ends closer to compliance with my view of how things should work. But by doing this myself I have managed to have much lower latency deploying things like fully functional PKCS#11 and TPM support — while the curl mindset would generally (rightly) be that the crypto libraries themselves should be getting that right for us. And tilting at *that* windmill takes a lot longer. I'm genuinely not sure if I should be trying to use curl here at all. I was unhappy back in 2008 when I concluded I needed to do my own HTTP code, but I came to live with it. Switching to curl right now would be a fair amount of work, and would almost certainly cause usability and functional regressions. But the recent CVE took me right back to my original level of unhappiness, and the realisation that *if* I'd started using curl ten years ago, we'd probably have reached the point where it *does* meet my requirements. So now I'm wondering if I should do it, but I'm really not sure... > > hands the connection back to me > > That sounds like maybe a job for CURLOPT_CONNECT_ONLY and > CURLINFO_ACTIVESOCKET ? For CONNECT requests and IF-T/TLS Upgrade requests which get a 101 'Switching Protocols' response, I think it's fine. I'd need a hackish special case for the crappy Juniper protocol where the 'upgrade' gets a 200 response but then goes straight into binary exchange of IP packets.
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
