# What can a proxy provider see? HTTPS vs plain HTTP > Over HTTPS a proxy provider sees each hostname, port, time and byte count, never the pages or passwords. Over plain HTTP it sees everything you send. Source: https://mosaicbrowser.com/blog/what-a-proxy-provider-can-see ## What your proxy provider can and cannot see Over HTTPS a proxy provider sees each hostname, port, time and byte count, never the pages or passwords. Over plain HTTP it sees everything you send. ![HTTPS versus Plain HTTP, each name in its own tile: What the gateway reads, and what it cannot](https://mosaicbrowser.com/covers/what-a-proxy-provider-can-see.webp) Short answer: a proxy provider sees the hostname, the port, the time and the byte count of every connection you make through it. If the site is HTTPS, that's the lot. The path after the hostname, your cookies, the form you fill in — all of it is encrypted end to end, and the gateway is shovelling ciphertext. Load a plain `http://` page, though, and the gateway reads the request and the response word for word. We'd draw the line right there before signing in to anything through somebody else's server. ## What a CONNECT request tells the gateway Behind an HTTP proxy, Chrome never hands an HTTPS request to the gateway. It asks for a tunnel instead (the CONNECT method, RFC 9110 section 9.3.6). Here is the preamble, in the order Chrome's `proxy_client_socket.cc` writes it, which we copied line for line when we rebuilt our relay: ``` CONNECT example.com:443 HTTP/1.1 Host: example.com:443 Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Macintosh; ...) Chrome/... Proxy-Authorization: Basic ... ``` Five lines, and they're the only plaintext the gateway gets. Host and port. Your User-Agent. And `Proxy-Authorization`, which tells it which customer is asking. Then it replies `200` and from that moment it's a pipe. The first bytes down that pipe are the TLS ClientHello. It names the site again in the SNI field (unless Encrypted Client Hello is in play), and its layout is the browser's TLS fingerprint. So the gateway can read that too. Nothing new, mind: it already had the hostname from the CONNECT line. One thing that is easy to forget: the provider already knows who you are. You have an account with it, paid for it and authenticate on every request. So the question is not whether the gateway can identify you. It is what the gateway can read beside your name. Mosaic is a desktop app Email yourself the link and open it on your computer. [How it works: Local first](https://mosaicbrowser.com/features/local-first) ## What a proxy provider cannot see over HTTPS Inside the tunnel, everything is ciphertext to the gateway: - the path and query string (`/orders?page=2`, search terms, tokens in URLs) - request and response headers, including every cookie - page content, form fields and passwords - which of several requests on one connection went where, since HTTP/2 multiplexes them in one tunnel What it can still measure is the outside of the traffic. It knows when each tunnel opened and closed and how many bytes moved, and from that a patient observer can guess at things like the size of a download. Getting past TLS would take a certificate your browser trusts and the gateway holds, and that only happens if somebody installed one. A gateway that tried it without one would put `NET::ERR_CERT_AUTHORITY_INVALID` on every page. ## SOCKS5 shows about the same RFC 1928 gives a SOCKS5 connect request three ways to name where it's going: IPv4, IPv6, or a domain name, which is address type `0x03`. Chrome uses the domain name. So does our relay: `socks.ts` writes `05 01 00 03`, then the length, then the host. The gateway does the DNS lookup itself, which means it knows the host just as surely as it would from a CONNECT line. After that it's the CONNECT story again. Hostname, port, when, how much. ## What it can see over plain HTTP There's no tunnel for a plain `http://` page. Chrome hands the proxy the request itself, URL and all, which RFC 9110 calls absolute form: ``` GET http://example.com/login?next=/account HTTP/1.1 Host: example.com Cookie: session=... ``` The gateway reads the full address, every header, every cookie and any form body, and then the whole response. A password typed into an `http://` page goes through it in the clear. Choosing an `https://` proxy type only encrypts the hop between you and the gateway; the gateway itself still reads the request. We do this ourselves, on purpose. Mosaic's proxy check sends `GET http://ip-api.com/json/?fields=...` through the proxy to learn the exit's country, city and timezone, then asks `http://edns.ip-api.com/json` which DNS resolver the exit uses. Your provider can read both requests top to bottom. That's fine: there's no cookie in them, no login, nothing worth reading. What that check measures is in [how to check a proxy before you use it](https://mosaicbrowser.com/guides/how-to-check-a-proxy-before-you-use-it). ## The line to draw before you trust a seller Sign in over HTTPS and your password and session cookie stay out of the gateway's reach. What it may keep is a log: hostnames and times, filed under your customer account. That log matters in its own right, because it links your proxy account to every site you visited through it. Before we'd trust a seller with an account, we'd ask three things. Is every site we sign in to HTTPS all the way, redirects and single-sign-on hops included? Has the provider ever asked us to install a root certificate? (An ordinary residential or datacentre proxy has no reason to, and one that does can read everything.) And how long do their terms say hostname logs are kept? ## What the gateway sees from Mosaic The gateway also sees the shape of the CONNECT request itself. A relay that writes it differently from Chrome tells the provider that a script is in the middle, which ours did until we matched it line for line, in [the relay that told the gateway it was a script](https://mosaicbrowser.com/blog/the-relay-that-looked-like-a-script). The order Chrome writes request headers in, and why it survives a proxy, is in [Chrome's header order through a proxy](https://mosaicbrowser.com/blog/chrome-header-order-through-a-proxy). That relay runs on your own computer, on a loopback address, one per profile, and goes straight to the gateway. Proxied traffic never passes through anything of ours on the way, because profiles, cookies and proxies stay on your computer ([local-first, explained](https://mosaicbrowser.com/features/local-first)). ## Questions ### Can my proxy provider see my passwords? Not on an HTTPS page. The password goes inside TLS from your browser to the site, so the gateway just carries scrambled bytes. On a plain http:// page it can, since the form post goes through it as text. ### Can a proxy provider see which websites I visit? Yes, the hostnames. Every HTTPS tunnel starts with something like CONNECT shop.example:443, and the provider can log that and the time. It never sees /orders?page=2 or what the page said. ### Does a SOCKS5 proxy see less than an HTTP proxy? About the same. A SOCKS5 connect request carries the destination as a hostname or an address, then the gateway relays bytes. Over HTTPS those bytes are encrypted either way. ### Can a proxy provider see my cookies? Not on HTTPS. A cookie is a request header, and headers travel inside the encrypted tunnel. On plain HTTP the Cookie: line goes past the gateway in the clear, along with the rest of the request. ### Does Mosaic see my proxied traffic? No. Mosaic adds a proxy's username and password with a small relay that listens on 127.0.0.1, on your own machine, one per profile, and it connects straight to the provider's gateway. We have no server anywhere in that path. ## Related [Our proxy relay told the gateway it was a script](https://mosaicbrowser.com/blog/the-relay-that-looked-like-a-script): Chrome sends Proxy-Connection: keep-alive, lower case, to every proxy. Our relay sent Keep-Alive, no User-Agent and Connection: close, until we copied Chrome. [Header order is a fingerprint, and a tunnel cannot touch it](https://mosaicbrowser.com/blog/chrome-header-order-through-a-proxy): Sites read the order of Chrome's HTTP headers as well as their values. Through a CONNECT tunnel a relay carries ciphertext, so it cannot reorder a thing. [How to check a proxy before you use it](https://mosaicbrowser.com/guides/how-to-check-a-proxy-before-you-use-it): Check that a proxy answers and tunnels, where its exit really is, whether the address is residential or blocklisted, and that the browser stays behind it. [Local first: your profiles stay on your computer](https://mosaicbrowser.com/features/local-first): Mosaic has no cloud copy of your profiles. Profiles, cookies and proxies stay on your computer, encrypted on disk, with app lock, daily backups and a trash.    [Why hCaptcha gives some browsers a puzzle every time](https://mosaicbrowser.com/blog/hcaptcha-image-challenge-every-time): hCaptcha's challenge is its score. A puzzle every time usually means blocked cookies, a crowded VPN exit or a browser whose values disagree with each other. ## Mosaic, on your own computer The browser this blog is about: its own Chromium, fingerprints from real machines and a proxy exit per profile. Free holds 3 profiles. Pro is $49 a month for any number. Mosaic is a desktop app Email yourself the link and open it on your computer.