4 ms·

> OpenSSL versions with the same major number are API and ABI compatible Finally! > A proper HTTP(S) client in libcrypto supporting GET and POST, redirection,

> OpenSSL versions with the same major number are API and ABI compatible Finally! > A proper HTTP(S) client in libcrypto supporting GET and POST, redirection, plain and ASN.1-encoded contents, proxies, and timeouts Is this really necessary? If you want a 'real' http client, you're probably using libcurl anyway (which is permissively licensed, more stable, and supports http/3).

JoshTriplett 6y ago
> Is this really necessary? If you want a 'real' http client, you're probably using libcurl anyway (which is permissively licensed, more stable, and supports http/3). I'd guess it's there to support cryptographic protocols that require downloading/checking keys via HTTPS. Right before that line is "Implementation of the Certificate Management Protocol (CMP, RFC 4210) also covering CRMF (RFC 4211) and HTTP transfer (RFC 6712)". And yes, use curl.
hannob 6y ago
Up until now OCSP checks were basically broken in openssl for all OCSP servers which speak only HTTP/1.1 (which is most of them) and only worked with a crude hack where you add an extra HTTP header via command line. Not sure if this fixes it, but if you include functionality that relies on HTTP then you better support HTTP.
Tobu 6y ago
HTTPS is a really huge scope to tackle, and requires a lot of policy which OpenSSL traditionally hasn't encoded (how to root trust, for example — possibly involving system stores or custom ones, stapling, pinning…). Also, OpenSSL generally is embedded in HTTP clients, and having distinct implementations of HTTP calling into each other from the same library seems terrible, with potential for security issues related to policy or implementation mismatches. Of course, there's all the traditional bug surface of any code that talks to the network to consider as well. Defining an interface for calling back into another HTTP library might be doable, but there's still a question of scope creep. The motivation seems to be this fork and pull request: - https://github.com/mpeylo/cmpossl https://github.com/mpeylo/cmpossl - https://github.com/openssl/openssl/issues/5926 https://github.com/openssl/openssl/issues/5926 The use case is far away from what most users of OpenSSL need, and could quite easily be tackled outside OpenSSL.

JoshTriplett 6y ago

> Is this really necessary? If you want a 'real' http client, you're probably using libcurl anyway (which is permissively licensed, more stable, and supports http/3). I'd guess it's there to support cryptographic protocols that require downloading/checking keys via HTTPS. Right before that line is "Implementation of the Certificate Management Protocol (CMP, RFC 4210) also covering CRMF (RFC 4211) and HTTP transfer (RFC 6712)". And yes, use curl.

hannob 6y ago

Up until now OCSP checks were basically broken in openssl for all OCSP servers which speak only HTTP/1.1 (which is most of them) and only worked with a crude hack where you add an extra HTTP header via command line. Not sure if this fixes it, but if you include functionality that relies on HTTP then you better support HTTP.

Tobu 6y ago

HTTPS is a really huge scope to tackle, and requires a lot of policy which OpenSSL traditionally hasn't encoded (how to root trust, for example — possibly involving system stores or custom ones, stapling, pinning…). Also, OpenSSL generally is embedded in HTTP clients, and having distinct implementations of HTTP calling into each other from the same library seems terrible, with potential for security issues related to policy or implementation mismatches. Of course, there's all the traditional bug surface of any code that talks to the network to consider as well. Defining an interface for calling back into another HTTP library might be doable, but there's still a question of scope creep. The motivation seems to be this fork and pull request: - https://github.com/mpeylo/cmpossl https://github.com/mpeylo/cmpossl - https://github.com/openssl/openssl/issues/5926 https://github.com/openssl/openssl/issues/5926 The use case is far away from what most users of OpenSSL need, and could quite easily be tackled outside OpenSSL.