The --resolve option is very helpful for using curl to direct requests to the proxy to terminate.

curl -k -v --resolve ''

Adding the -k assuming you are using a self-signed cert in ATS for testing.  Also assuming your ATS is configured to listen for TLS on port 4443 in this example.

On Thu, Dec 3, 2020 at 1:29 PM Alan Carroll <> wrote:
You will need to set up the certificates for ATS in that case. Although it is possible to do this in "records.config", that is (IMHO) deprecated because it has been superceded by "ssl_multicert.config". I would start with that directly, it will be easier.
If there is only a single certificate, you will want to use "dest_ip=*" as the configuration which will use that certificate for all outbound connections.
You'll need to use different options to curl to test this, as using "--proxy" with an "https" destination will always bypass TLS on the proxy.

On Thu, Dec 3, 2020 at 1:03 PM Lei Sun <> wrote:
Hi Alan,

Thanks for responding! Yes, I learned about the CONNECT method.

I can confirm that for the "https" method, I don't want the client to do TLS directly with the server. Instead, I'd like the trafficserver to take that request, decrypt it, then pretend to be a client, and do TLS on behalf of the client with the upstream.


On Thu, Dec 3, 2020 at 12:13 PM Alan Carroll <> wrote:
The first thing to note is "curl --proxy" behaves very differently if the target URL is "http" vs. "https". In the former case, curl will do a TCP network connection to the proxy and then sends a GET request. In the latter case, as you can see from the output, it does a TCP network connection to the proxy and then sends a CONNECT (not a GET) to the proxy. After this, curl will do TLS negotiation with the upstream, NOT with ATS. It is unclear from your description if this is what you want.

So, first question - should ATS do TLS negotiation with the user agent and decrypt the request? Or should it just do a blind tunnel pass the raw bytes to the upstream so the upstream does the TLS with the user agent?

On Wed, Dec 2, 2020 at 5:41 PM Lei Sun <> wrote:
Hi Kit,

I'm trying to set up the trafficserver as an intermediary forward proxy.

For example, 
1) http client send request to trafficserver.
2) trafficserver then pass this request to the downstream proxy
3) downstream proxy then route this request to the origin site
4) origin site send data back to the downstream proxy
5) downstream proxy send data back to trafficserver
6) trafficserver send data back to the http client.

I was able to make the entire request chain work if the origin site serves content directly through HTTP.
curl --proxy -v

However, I ran into issues when I was trying to request for content served from HTTPS.

$ curl --proxy -v
*   Trying
* Connected to ( port 8080 (#0)
* Establish HTTP proxy tunnel to
> Host:
> User-Agent: curl/7.54.0
> Proxy-Connection: Keep-Alive
< HTTP/1.1 200 OK
< Date: Wed, 02 Dec 2020 20:53:31 GMT
< Proxy-Connection: keep-alive
< Server: ATS/10.0.0
* Proxy replied OK to CONNECT request
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* error:1400410B:SSL routines:CONNECT_CR_SRVR_HELLO:wrong version number
* stopped the pause stream!
* Closing connection 0
curl: (35) error:1400410B:SSL routines:CONNECT_CR_SRVR_HELLO:wrong version number

From the error message, it seems that curl was able to connect to the origin server, and even attempted to send the initial TLS handshake, but somehow the handshake wasn't completed.

Here are my questions.
1) What's likely the cause?
2) How can I fix it.

Thank you!