Introducing Smartpath®: AI-Powered Residential Proxy Optimization That Cuts Bandwidth Costs by 40%
BlogAnnouncing Residential Network HTTP/S Support

Announcing Residential Network HTTP/S Support

HTTPS.png

HTTPS proxy support is now available to use across our residential network. Use the beta.residential.pingproxies.com hostname and set your scheme to HTTPS and your client will do the rest... it requires no additional effort on your part to take advantage of this enhanced security. In the coming weeks we will be pushing even more protocols and features to this beta branch of Ping Proxies and we hope to merge these features into our production network not long after.

With the headline out of the way, what does this actually mean for you? Well, many of our customers work in industries such as healthcare and banking with strict rules (i.e. HIPAA) on the handling of confidential and sensitive data. Our addition of HTTPS adds an extra layer of security on top of their requests, guaranteeing this data is as safe as can possibly be.

To be clear, if your proxies are configured correctly, all data sent through the proxy will already use HTTPS (and therefore encryption) when communicating with the target website but the initial message to the proxy server to establish a proxy tunnel would be unencrypted. This means it was possible for somebody to see that you were using a proxy, where you wanted to proxy to and your proxy credentials. Now, even this initial handshake can be protected with “military grade encryption”, wrapping all data between your client machine and our servers inside an extra layer of encryption.

As mentioned, simply set your proxy string to use beta.residential.pingproxies.com and your scheme to HTTPS to take advantage of these features. Watch the video below to see how to use these features in the command-line.

HTTPS Proxy Example.gif

Using With CURL

If you wish to use HTTPS with curl you can use the following command:


curl -U USER:PASS -x https://beta.residential.pingproxies.com:8306 YOUR-TARGET

Using the '-v' flag will let you see what's going on. With the above command, TLS is negotiated with the proxy server, a proxy tunnel is established, TLS is negotiated with the end server and finally your request is sent and the response received.

Example
> curl -U USER:PASS -x https://beta.residential.pingproxies.com:8306 https://cloudflare.com/cdn-cgi/trace

-- Establishing connection to proxy server
* Host beta.residential.pingproxies.com:8306 was resolved.
* IPv6: (none)
* IPv4: 51.158.201.205
*   Trying 51.158.201.205:8306…


-- Negotiating TLS encryption between your machine and the proxy server
ALPN: curl offers http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
[REDACTED FOR BREVITY]


-- Executing proxy handshake to establish tunnel to Cloudflare
* CONNECT tunnel: HTTP/1.1 negotiated
* allocate connect buffer
* Proxy auth using Basic with user '[REDACTED CREDENTIALS]'
* Establish HTTP proxy tunnel to cloudflare.com:443
> CONNECT cloudflare.com:443 HTTP/1.1

-- Negotiating TLS encryption and HTTP/2 between your machine and Cloudflare
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
[REDACTED FOR BREVITY]

-- Sending HTTP/2 request to Cloudflare and receiving response
* [HTTP/2] [1] OPENED stream for https://cloudflare.com/cdn-cgi/trace
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: cloudflare.com]
* [HTTP/2] [1] [:path: /cdn-cgi/trace]
* [HTTP/2] [1] [user-agent: curl/8.14.1]
* [HTTP/2] [1] [accept: */*]

-- Cloudflare response showing location of the proxy
fl=1032f32
h=cloudflare.com
ip=95.25.232.40
ts=1754995005.809
visit_scheme=https
uag=curl/8.14.1
colo=ARN
sliver=none
http=http/2
loc=RU
tls=TLSv1.3
sni=plaintext
warp=off
gateway=off
rbi=off
kex=X25519MLKEM768

Tech Talk

Due to a lack of understanding of proxying and the complexity that comes with the availability of many different protocols, it can be difficult to talk about proxies without causing confusion. To help with this, let's give you a high level overview of what proxies do and how to talk about them.

Proxying can be broken down into two stages: the handshake and the tunnel. The handshake is where you and the proxy server get on the same page so that the transfer of data can begin. The tunnel is where this transfer of data happens.

In the handshake, you tell the server where you want to be proxied too, what sort of proxy you might want (residential geotargeting for example) and the credentials you've been given to access the proxy. The server decides whether or not to let you use it, connects you to your target and lets you know that the tunnel stage has begun.

In the tunnel stage it acts as a simple relay, passing bytes from you to the server and from the server to you. Typically, if the target you wanted to connect to was a HTTPS target, you will communicate with the target over this tunnel to establish some level of encryption. This encryption will then hide all the bytes you send through the tunnel from us (the proxy server) and your ISP too. Once the encryption is established you will send your request (i.e. a GET request) to the target server.

If you don't establish any encryption with the proxy server then the handshake stage will be unencrypted and all the information in the handshake will be visible to your ISP (for example). This is known as an HTTP proxy and is the standard within the industry. If the scheme of your proxy string is HTTP then your handshakes are unencrypted.

A HTTPS proxy is one where you do both an encrypted handshake and an encrypted tunnel. This is what the rollout of HTTPS to our residential servers allows you to do. By adding HTTPS to your proxy string scheme you can hide your target website and proxy credentials inside a layer of encryption.

You can see how confusion may arise when talking about HTTP versus HTTPS proxies. Most providers who say they offer HTTPS proxies actually mean that they support the CONNECT method on HTTP requests (the handshake and tunneling process we mentioned above) which lets you form an encrypted tunnel to the target server. We’ve offered these HTTPS proxies since we founded Ping. Now, when we say that we offer HTTPS proxies, we mean HTTPS to the proxy server on top of the HTTPS to the end server that you were already doing.


Supported Encryption Methods for Our Products
Product HTTP to Proxy HTTPS to Proxy HTTPS to Target
Datacenter
ISP
Residential

Having Issues?

For now, HTTPS to the proxy server is only supported on our beta residential network but in the near future we hope to add this feature to our ISP and Datacenter product lines too. While using this feature you may experience some request failures and network outages whilst we iterate upon this feature. For any issues you encounter, please reach out to our support team.

Residential ProxiesResidential Proxies
  • 35 million+ real residential IPs

  • 195+ countries

  • Less than 0.5 second connect times

cookies
Use Cookies
This website uses cookies to enhance user experience and to analyze performance and traffic on our website.
Explore more