Een proxy server kan natuurlijk http verkeer inzien, want deze is niet versleuteld.

De proxy server kan NIET https verkeer inzien.

Download privoxy eens, om te experimenteren.

Ik weet niet wat je precies bedoelt met een "https proxy".

Bij TLS v1.2 en ouder zal, i.v.m. SNI, sowieso de gewenste domeinnaam uit het request zichtbaar zijn.

Als die proxy server ook http (default destination port 80) ondersteunt, en ofwel jij tikt in de URL-balk:

1) http://example.com

2) example.com en jouw browser maakt daar "onder water" geen https://example.com van (omdat die site HSTS ondersteunt en je deze recentelijk hebt bezocht met die browser, en/of omdat je een recente browser gebruikt die sowieso eerst https probeert als je geen protocol specificeert):

dan zal die proxy server dat request en een eventueel antwoord daarop in plain text zien.

Als jouw browser een verbinding op probeert te zetten met https://example.com via de proxy server, hangt het van het type proxy server af wat er gebeurt. Als deze TLS-inspectie uitvoert (gebruikelijk is dan dat er daarvoor op jouw PC een speciaal root-certificaat is geïnstalleerd), is die proxy een MitM waarop ontsleuteld verkeer zichtbaar is (voorbeeld: mitmproxy).

Duidelijk en compleet verhaal.
Met https proxy bedoel ik een HTTPS proxy server. Zoals er naast HTTPS proxy servers ook HTTP-, SOCKS4- en SOCKS5- proxyservers bestaan.

Ben je niet in de war met een reverse proxy ?

Een gewone proxy server zet geen HTTP om naar HTTPS .

Als je een proxy server gebruikt die ook HTTPS ondersteund, stuurt je browser een CONNECT request met de gevraagde bestemming naar de proxy .
Alle verkeer van je browser naar de proxy, en naar de bestemming, is HTTPS verkeer .

Het zijn alleen twee TCP sessies - en sessie naar de proxy, en een sessie van de proxy naar de bestemming .
De proxy kopieert het data verkeer heen en weer tussen beide sessies.

n principe zou dat ook ander verkeer kunnen zijn - veel SSH clients hebben de optie om 'via' een proxy te werken - ze sturen de connect request en de proxy kan evengoed SSH verkeer heen en weer kopieren .
Alleen als de proxy expliciet kijkt of het format SSL/TLS is werkt dat niet.


De URL die je in je browser intikt is dus ook HTTPS://bestemming /

Een _reverse_ proxy, ook wel een 'SSL offload engine' , zit aan de bestemmingskant . Dat is een server, of een appliance zoals een loadbalancer, met als taak het ontvangen en uitpakken van alle SSL sessies . Het HTTP verkeer daarin wordt daarna doorgezet naar de achterliggende set van webservers .
Achter die reverse proxy is het verkeer dus wel weer leesbaar .

Nou het is misschien duidelijk, maar compleet is het niet, want Erik weet niet wat een https proxy is.
Als je via een https proxy verbindt dan weet die proxy altijd de hostnaam en het poortnummer.
Dat heeft met SNI en het eventueel encrypted zijn daarvan niks te maken.

Een https proxy krijgt van de browser het volgende commando:
CONNECT www.security.nl:443

Dat dus in plaintext. De proxy maakt dan die verbinding en schakelt die 1:1 door naar de client. Er zijn daarna
dus 2 TCP connecties: een van de client naar de proxy (meestal poort 3128 of soms 8080 ofzo) en een van de
proxy naar het doelststeem. Deze kunnen ook een verschillende IP versie zijn (IPv4 vs IPv6).
De proxy hevelt alle data over van de ene naar de andere connectie.

De hele TLS onderhandeling vindt vervolgens plaats via die geschakelde verbinding. Daar kan de proxy verder
niet zoveel meer aan zien, hetzelfde als ieder ander die met de connectie kan meekijken.

Als het een echte HTTPS-proxy is: ja, dan is dat verkeer te zien. En jij ziet ook dat de proxy ertussen zit, want je certificaat is van de proxy, niet van de site. Een MiTM situatie dus.

Meer hierover staat op https://www.ncsc.nl/documenten/factsheets/2019/juni/01/factsheet-tls-interceptie.

Zit je niet in een bedrijfsnetwerk? Dan is een (https-)proxy eigenlijk echt een no-go. Tenzij je natuurlijk met Burp aan de slag bent of andere pen-test tools (want jij bent dan zelf de MiTM :)).

Kwestie van met certificaten spelen, eigen certificaat op de cliënt en de proxy en voila, met wat truukjes heb je een intercepting proxy a la Bluecoat gebouwd. SSL intercepting (hoewel het tegenwoordig TLS heet) kan dus wel degelijk. Alleen TLS 1.3 is nog lastig.

Klopt! En niet alleen ik weet dat niet: als ik Google naar https proxy krijg ik geen eenduidig antwoord. Er zijn proxies die TLS "openbreken" (waarbij er feitelijk twee verschillende TLS verbindingen zijn) en die dat niet doen. Er zijn er zelfs die beide ondersteunen (verbindingen met whitelisted websites niet openbreken, en de rest wel).

Op veel plaatsen zie je dat een proxy server een application level gateway is; daar heeft het weinig meer mee te maken als er alleen maar versleutelde data door wordt uitgewisseld.