1
0
mirror of https://github.com/moparisthebest/curl synced 2024-11-10 11:35:07 -05:00
curl/include
Alex Rousskov cb4e2be7c6 proxy: Support HTTPS proxy and SOCKS+HTTP(s)
* HTTPS proxies:

An HTTPS proxy receives all transactions over an SSL/TLS connection.
Once a secure connection with the proxy is established, the user agent
uses the proxy as usual, including sending CONNECT requests to instruct
the proxy to establish a [usually secure] TCP tunnel with an origin
server. HTTPS proxies protect nearly all aspects of user-proxy
communications as opposed to HTTP proxies that receive all requests
(including CONNECT requests) in vulnerable clear text.

With HTTPS proxies, it is possible to have two concurrent _nested_
SSL/TLS sessions: the "outer" one between the user agent and the proxy
and the "inner" one between the user agent and the origin server
(through the proxy). This change adds supports for such nested sessions
as well.

A secure connection with a proxy requires its own set of the usual SSL
options (their actual descriptions differ and need polishing, see TODO):

  --proxy-cacert FILE        CA certificate to verify peer against
  --proxy-capath DIR         CA directory to verify peer against
  --proxy-cert CERT[:PASSWD] Client certificate file and password
  --proxy-cert-type TYPE     Certificate file type (DER/PEM/ENG)
  --proxy-ciphers LIST       SSL ciphers to use
  --proxy-crlfile FILE       Get a CRL list in PEM format from the file
  --proxy-insecure           Allow connections to proxies with bad certs
  --proxy-key KEY            Private key file name
  --proxy-key-type TYPE      Private key file type (DER/PEM/ENG)
  --proxy-pass PASS          Pass phrase for the private key
  --proxy-ssl-allow-beast    Allow security flaw to improve interop
  --proxy-sslv2              Use SSLv2
  --proxy-sslv3              Use SSLv3
  --proxy-tlsv1              Use TLSv1
  --proxy-tlsuser USER       TLS username
  --proxy-tlspassword STRING TLS password
  --proxy-tlsauthtype STRING TLS authentication type (default SRP)

All --proxy-foo options are independent from their --foo counterparts,
except --proxy-crlfile which defaults to --crlfile and --proxy-capath
which defaults to --capath.

Curl now also supports %{proxy_ssl_verify_result} --write-out variable,
similar to the existing %{ssl_verify_result} variable.

Supported backends: OpenSSL, GnuTLS, and NSS.

* A SOCKS proxy + HTTP/HTTPS proxy combination:

If both --socks* and --proxy options are given, Curl first connects to
the SOCKS proxy and then connects (through SOCKS) to the HTTP or HTTPS
proxy.

TODO: Update documentation for the new APIs and --proxy-* options.
Look for "Added in 7.XXX" marks.
2016-11-24 23:41:44 +01:00
..
curl proxy: Support HTTPS proxy and SOCKS+HTTP(s) 2016-11-24 23:41:44 +01:00
Makefile.am added to enable include file install 2000-07-31 22:40:52 +00:00
README s/cURL/curl 2016-11-07 10:36:23 +01:00

                                  _   _ ____  _
                              ___| | | |  _ \| |
                             / __| | | | |_) | |
                            | (__| |_| |  _ <| |___
                             \___|\___/|_| \_\_____|

Include files for libcurl, external users.

They're all placed in the curl subdirectory here for better fit in any kind
of environment. You must include files from here using...

        #include <curl/curl.h>

... style and point the compiler's include path to the directory holding the
curl subdirectory. It makes it more likely to survive future modifications.

NOTE FOR LIBCURL HACKERS

The following notes apply to libcurl version 7.19.0 and later.

* The distributed curl/curlbuild.h file is only intended to be used on systems
  which can not run the also distributed configure script.

* The distributed curlbuild.h file is generated as a copy of curlbuild.h.dist
  when the libcurl source code distribution archive file is originally created.

* If you check out from git on a non-configure platform, you must run the
  appropriate buildconf* script to set up curlbuild.h and other local files
  before being able of compiling the library.

* On systems capable of running the configure script, the configure process
  will overwrite the distributed include/curl/curlbuild.h file with one that
  is suitable and specific to the library being configured and built, which
  is generated from the include/curl/curlbuild.h.in template file.

* If you intend to distribute an already compiled libcurl library you _MUST_
  also distribute along with it the generated curl/curlbuild.h which has been
  used to compile it. Otherwise the library will be of no use for the users of
  the library that you have built. It is _your_ responsibility to provide this
  file. No one at the curl project can know how you have built the library.

* File curl/curlbuild.h includes platform and configuration dependent info,
  and must not be modified by anyone. Configure script generates it for you.

* We cannot assume anything else but very basic compiler features being
  present. While libcurl requires an ANSI C compiler to build, some of the
  earlier ANSI compilers clearly can't deal with some preprocessor operators.

* Newlines must remain unix-style for older compilers' sake.

* Comments must be written in the old-style /* unnested C-fashion */

To figure out how to do good and portable checks for features, operating
systems or specific hardwarare, a very good resource is Bjorn Reese's
collection at http://predef.sf.net/