Unless they ask you to install their own certificate or you see unsafe connection message when visiting twitters website, then no.
They can only see donain names you are visiting (by TLS SNI and Host: headers).
No they can't.
No they can't.
No they can't.
No they can't.
When you visit Twitter (or any website) over https/TLS (https://), your connection is encrypted to protect your data from being intercepted or tampered with. Let's go through each proxy type and see if the proxy provider can see through the TLS encryption:
- HTTP Proxy: Although you're using an HTTP proxy, the TLS encryption is still in place when you access Twitter over https://. The proxy provider can see the domain (e.g., twitter.com) you're connecting to, but they cannot see the specific content or your login credentials, as they are encrypted.
- HTTPS Proxy: Similar to an HTTP proxy, when you use an HTTPS proxy to visit Twitter over https://, the proxy provider can see the domain you're connecting to, but the content and login credentials remain encrypted and protected.
- SOCKS4/5 Proxy: SOCKS proxies work at a lower level than HTTP/HTTPS proxies and are not protocol-specific. When visiting Twitter over https://, your TLS encryption is maintained. The proxy provider can see the domain you're connecting to but cannot see the encrypted content or login credentials.
- 4G Proxy: 4G proxies use mobile IP addresses and work similarly to other proxy types in terms of encryption. When visiting Twitter over https://, the TLS encryption remains in place. The proxy provider can see the domain you're connecting to but not the encrypted content or login credentials.
In summary, when you visit Twitter (or any website) over https://, the TLS encryption protects your data regardless of the proxy type you use. While the proxy provider can see the domain you're connecting to, they cannot see the specific content or your login credentials due to the encryption.
What about the following quotes?
"HTTP and HTTPS proxies differ in the way they handle HTTPS connections. HTTP proxies can handle HTTPS connections, but they only see the encrypted traffic that is sent between the client and the server. This means that they can't see the content of the traffic, including any sensitive information such as passwords or credit card details. On the other hand, HTTPS proxies are specifically designed to handle encrypted traffic. They can decrypt the traffic and inspect its contents, which allows them to provide additional security features such as content filtering and intrusion detection. This also means that HTTPS proxies can see any sensitive information that is being transmitted, so it's important to ensure that they are properly secured."
"Yes, https proxies decrypt your https traffic. They do a key exchange with the remote server on your behalf, and you do a key exchange with the proxy.
Http proxies just wrap your traffic up a little bit.
If you're using an actual https proxy, then yes the proxy owns your traffic. If you're just using a VPN of some sort, generally that's not an https proxy. You can identify https proxies because your browser will complain for every https site you try to connect to that the certificate doesn't match the endpoint (cert will be the proxy's). Unless the proxy cert is in your root CA store... which you may have unknowingly put there, or maybe a hacker got into your system and put it there (unlikely unless it's a work computer, then everything's on the table)."
"When you use an HTTP proxy, what you're actually doing is requesting the proxy set up a tunneled connection, and then relay the raw TCP stream between you and the destination. You and the server use this raw TCP stream to set up your TLS session, and while the proxy can see your TCP traffic, it can't see inside the TLS session.
Bottom line: single TLS session that passes through the HTTP proxy, and the proxy can't see inside.
When you use an HTTPS proxy, you establish a TLS session that terminates
at the proxy. You then ask the proxy to retrieve the destination URL
for you - the proxy then connects to the destination server, sets up its own TLS session, retrieves the content, and sends it back to you.
Bottom line: two TLS sessions - one from you to the proxy, and one from the proxy to the destination. The proxy necessarily has to be able to see incoming cleartext traffic (in both directions) in order to re-encrypt it and pass it on."
"On the proxy server itself, ALL traffic can be read as that is the place where all TLS encryption is removed before being re-encrypted and passed up/downstream. Upstream from the proxy server, all external servers think they're talking directly to the proxy. Downstream from the proxy server, all devices think the proxy server is actually the external server, because the server public key the proxy server returns to the requesting device in the HTTPS response is generated on-the-fly to look like it came from
www.google.com or
www.facebook.com, etc. Some services and usages are smarter than a proxy server, though, and can recognize when your proxy server's "fake" certificate isn't actually the same expected certificate for <public website> (look up certificate stapling for more). For example, heres a list of Apple hosts whose traffic the core OS of macOS/iOS can recognize as being encrypted with Apple's server's expected public certificates or something pretending to be Apple's servers:
https://support.apple.com/en-us/HT210060 For any host in the list that doesn't explicitly say it support proxies, any attempt to inspect and re-encrypt the traffic via a proxy server will be recognized on the receiving device as not being encrypted with Apple's ACTUAL public keys, and the service access attempt will disconnect as untrusted."
