curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: HTTPS using my own TLS session

From: David Woodhouse via curl-library <curl-library_at_cool.haxx.se>
Date: Fri, 20 Sep 2019 16:27:53 +0100

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.

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html

  • application/x-pkcs7-signature attachment: smime.p7s
Received on 2019-09-20