Tag Info

One of the early uses of HTTP proxies was caching proxies in order to make better use of the expensive bandwidth and to speed up surfing by caching heavily used content near the user. I remember a time when ISPs employed explicit mandatory proxies for the users. This was at a time when most content on the internet was static and not user-specific and thus ...

Having a proxy SSL certificate creates some privacy and security implications:
Superfish can impersonate any site
This does not mean that Superfish will do it (or is doing), but they have the power. As they have a Certification Authority Certificate, any certificate they generate will be valid and accepted.
Certificate pinning does not protect you, either:...

This is explained in their page on SSL proxying, perhaps not with enough explanations.
A proxy is, by definition, a man-in-the-middle: the client connects to the proxy, and the proxy connects to the server.
SSL does two things:
It ensures the confidentiality and integrity of the established connection.
It performs some verification of who you are ...

You seem to fundamentally misunderstand what TLS does.
TLS takes the regular plain HTTP traffic and encrypts it and adds integrity checks. Together with the certificate of the server, this ensures
Confidentiality: An attacker who captures the network traffic can not read the content of the communication.
Integrity: If an attacker modifies the network ...

They might do it already, there is a known technique to dedicate malicious and powerful nodes to the network to be able to take control of some of the traffic.
Tor does not advertise itself to be able to protect against adversaries that have control over a fair part of the internet. While there are techniques to check the validity of the nodes if you have ...

In Tor, the user (you) chooses a random path through several nodes for its data. The first node in the path knows your IP address, but not what you send or where. The last node ("exit node") knows the target server address and sees the data (unless SSL is used, of course), but not your IP address. Every node in the path knows only the addresses of the ...

Normally, when HTTPS is done through a proxy, this is done with the CONNECT mechanism: the client talks to the proxy and asks it to provide a bidirectional tunnel for bytes with the target system. In that case, the certificate that the client sees is really from the server, not from the proxy. In that situation, the proxy is kept on the outside of the SSL/...

With HTTPS, the SSL/TLS tunnel is established first, and HTTP traffic happens only within that tunnel. Some information still leaks:
If the client uses a proxy, the connection to the proxy looks like: CONNECT www.example.com:443 with the target server name. Alternatively, the client could send the target server IP address, but this is only marginally less ...

Checking headers off a list is not the best technique to assert a site's security. Services like securityheaders.io can point you in the right direction but all they do is compare against a list of proposed settings without any context about your application. Consequently, some of the proposals wont't have any impact on the security of an API endpoint that ...

As is customary, let's first answer the exact question which was asked.
Right now, using HTTPS to connect to the proxy is not widely supported. The squid documentation has some information on the subject; to sum things up:
Chrome supports it, but it must be configured through a proxy auto-configuration script because there is no GUI support. This also ...

How to know if your company does TLS intercept
As the post you linked to explains, the proxy will decrypt all the traffic, and then encrypt it again but signed with another certificate. Therefore the certificate you receive will be different from the one the website send. So one way to detect this is to compare the certificates you get when you visit a ...

Your forum accepts posts from anybody. That is your core problem. Connecting to your site from various IP throughout the world is trivial, if only by using Tor. Tor provides "high anonymity" in that not only the user's identity is hidden, but each request is anonymous -- you cannot, from the outside, make sure whether two distinct requests are from the same ...

A proxy will by default tell the destination the IP address of the original requester by adding a X-Forwarded-For HTTP header to the original HTTP request. This make it obviously easy for the server, not only to know that you are using a proxy, but also to know your actual IP address, effectively dropping your anonymity.
Then you have what is called an ...

It may be simpler to see it in stages. First, in a whole-HTTP world (no SSL whatsoever), an HTTP request is a collection of headers, indicating the target URL, and sent over a TCP connection (usually on port 80). The request headers begin with a "verb" which is usually GET or POST.
When there is a proxy, the request is sent to the proxy; the proxy then ...

Discussing this on Twitter is the modern day equivalent of Fermat discussing mathematical proofs via marginalia. So let us expand upon what Peter Wullinger did not have the space to fit into a margin a Twitter post.
There were, of course, other ways that the systemd people could have done this:
Advise system administrators to use ssh -x -- account@host ...

Some examples as follows:
To enable a firewall rule like 'proxy server to any destination on 80, 443' instead of from 'any internal to any external'
To monitor all websites visited through logs
To control, limit, filter websites visited through enforcing rules - these could be lists of approved sites, blacklisted sites, content categories etc
To enforce ...

TLS by itself protects the sniffing and modification of traffic between two endpoints, i.e. client and server. TLS interception just makes two TLS connections where only one was, i.e. client to interception device and interception device to server. This will still work with future TLS versions.
TLS interception is only possible if the validation of the ...

TL;DR - I think your problem is not related to SSL at all, but you are trying to use a proxy server without the proxy headers.
So, if I use stunnel to create an SSL tunnel, and then pass HTTP traffic through it, would it be the same as using HTTPS normally?
Yes. We use http over stunnel at work to talk to an https-server. That's a workaround for a bug in ...

If the connection uses proxies which are correctly implemented, discovering the ip through http or tcp can be difficult. You may have some luck in getting closer to the ip using DNS instead.
for
If you generate the page dynamically to contain an image located at a domain that you control, e.g.
<img src="http://123123.deanonymize.mydomain.com"/>
the ...

A SOCKS proxy is in a position similar to a router: it sees all traffic. It is thus in ideal position to commit various felonies on your data. You should consider it as you would consider any router on the Internet (including your ISP): it fulfills a service but you do not trust it. Using an external proxy is no less risky, but no more risky either, than ...

The way an investigator would trace a multi-hop connection to the original source is to follow each hop, and examine either the logs (if the connection is closed) or the network state (if the connection is ongoing) to see where the next hop goes. This can get very difficult if the hops cross political or jurisdictional borders, since the cooperation of ...

It's safe as long as you understand the implications.
Fiddler acts as a proxy / man in the middle to intercept and decrypt traffic between you and the target.
For SSL sites, it does this by dynamically generating an SSL certificate with the name of the target. The problem is that your browser will not trust certificates issued by Fiddler, hence the ...

Since version 1.1, HTTP supports a special method, CONNECT. This sets up the TLS tunnel through the proxy, even though your computer only directly connects to the proxy. HTTPS knows how to tunnel the TLS handshake even through the proxy.
See Wikipedia:
The CONNECT method converts the request connection to a transparent TCP/IP tunnel, usually to ...

A proxy understands the protocol it is designed for. This means that some proxy software can allow or disallow traffic based on elements of the protocol. To give an example, your proxy could disallow HTTP traffic with a certain User-Agent: header or only allow traffic with certain Referer: headers. A proxy can also require authentication before sending ...

Here are a few risks that you expose yourself to with this specific software:
It uses the same private key for each installation. Since the associated is a root CA and is inserted into your private trust list, it makes it trivial for ANYONE to generate any certificate and have it trusted by the affected client (in this case, even server certificate pinning ...

No.
AFAIK there is nothing inside the TLS 1.3 Draft about that. And I don't think there's a technical solution to this either. If you allow somebody to install an additional root CA on your computer, then all bets are off.

For the "original" reason, think back to 1993, when Netscape 0.9 was released. It had a "Mail and Proxies" Options dialog (per a copy of the manual). At that time, most Internet links were 56-kbit or fractional T1 lines between university campuses and government. There were several ways an HTTP proxy could help or even be required:
The web-browser might be ...

If the URL uses SSL (i.e. is https://) and use the proxy only for transport, then no, the proxy sees only encrypted data and cannot peek at it. (Unless the proxy tries to feed you with a forged certificate, which requires some prior installation of a collaborating CA in your machine; this may happen in work environments, when your enemy is the local sysadmin....