Om het gebruiksgemak te vergroten, de website te kunnen analyseren en om advertenties te kunnen beheren maakt Security.NL gebruik van cookies. Door gebruik te blijven maken van deze website, of door op de akkoord button te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer weten over cookies? Bekijk dan ons cookieoverzicht.
Nieuws Achtergrond Community
Inloggen | Registreren
Computerbeveiliging - Hoe je bad guys buiten de deur houdt

Sniffen https proxy

Reageer met quote
08-01-2021, 10:48 door Anoniem, 8 reacties
Als ik gebruik maak van een https proxy om example.com te bezoeken is mijn http request onderweg natuurlijk versleuteld.
De proxy zal vervolgens een connectie moeten opzetten naar example.com.

Maar hoe zit dit als mijn request eenmaal is aanbeland bij de https proxy-server, kan die wel de INHOUD van mijn http request inzien?
Foutje in certificaat-chain van www.snsbank.nl
SMB via WebSockets naar LAN
Reacties (8)
Reageer met quote
08-01-2021, 12:15 door Anoniem
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.
Reageer met quote
08-01-2021, 13:16 door Erik van Straten - Bijgewerkt: 08-01-2021, 13:17
Door Anoniem: Als ik gebruik maak van een https proxy om example.com te bezoeken is mijn http request onderweg natuurlijk versleuteld.
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).
Reageer met quote
08-01-2021, 13:31 door Anoniem
Door Erik van Straten:
Door Anoniem: Als ik gebruik maak van een https proxy om example.com te bezoeken is mijn http request onderweg natuurlijk versleuteld.
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.
Reageer met quote
08-01-2021, 14:51 door Anoniem
Door Anoniem:
Door Erik van Straten:
Door Anoniem: Als ik gebruik maak van een https proxy om example.com te bezoeken is mijn http request onderweg natuurlijk versleuteld.
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 .
Reageer met quote
08-01-2021, 17:35 door Anoniem
Door Anoniem:
Door Erik van Straten:
Door Anoniem: Als ik gebruik maak van een https proxy om example.com te bezoeken is mijn http request onderweg natuurlijk versleuteld.
Ik weet niet wat je precies bedoelt met een "https proxy".

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.

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.
Reageer met quote
08-01-2021, 21:25 door Anoniem
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 :)).
Reageer met quote
08-01-2021, 22:49 door Anoniem
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.
Reageer met quote
08-01-2021, 23:51 door Erik van Straten
Door Anoniem: Nou het is misschien duidelijk, maar compleet is het niet, want Erik weet niet wat een https proxy is.
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.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.

Je reactie is verstuurd en wordt zo spoedig mogelijk gemodereerd.

Verder
captcha
Nieuwe code
Preview Reageren
Zoeken
search

Werk jij nog thuis?

18 reacties
Aantal stemmen: 1284
Vacature
Image

Security Officer

36 - 40 uur

Als Security Officer zorg je dat het infrastructuur platform, de -broncode en de VECOZO werkplek van VECOZO zo min mogelijk kwetsbaarheden kennen. Dit doe je door kwetsbaarheden inzichtelijk te maken en op te lossen. Zo speel jij een cruciale rol in de beveiliging van al onze gegevens en bedrijfsmiddelen.

Lees meer
Mag mijn werkgever vragen of ik Corona heb (gehad) of gevaccineerd ben?
13-01-2021 door Arnoud Engelfriet

Juridische vraag: Als mijn werkgever van mij verlangt om aan te geven of ik Corona heb, dan wel mij heb laten testen of mij ...

16 reacties
Lees meer
Advertentie

Image

Certified Secure LIVE Online

Certified Secure is LIVE. Cross Site Scripting vinden en voorkomen? Met z'n allen een volledige kubernetes cluster compromitteren? Of gewoon voorkomen dat een collega op een phishing mail klikt? Ontwikkel ook terwijl je thuiswerkt je Hacker Mindset!

Zoals altijd zijn ook onze LIVE trainingen hands-on en met persoonlijke begeleiding van ervaren Certified Secure instructeurs. Direct vanuit je browser en dus zonder nasty extra software!

Neem contact met ons op voor de mogelijkheden voor jouw team.

Lees meer
SolarWinds: overzicht van een wereldwijde supply-chain-aanval
21-12-2020 door Redactie

Het risico van een supply-chain-aanval, waarbij aanvallers via software of systemen van een derde partij bij organisaties weten ...

15 reacties
Lees meer
Security.NL Twitter
04-11-2016 door Redactie

Altijd meteen op de hoogte van het laatste security nieuws? Volg ons nu ook op Twitter!

Lees meer
Nieuwe Huisregels en Privacy Policy

Op 5 december 2017 hebben we een nieuwe versie van onze huisregels en privacy policy ingevoerd. Om verder te kunnen gaan dien je eenmalig akkoord te gaan met de nieuwe huisregels van Security.NL.

Op 24 mei 2018 hebben we, in het kader van de AVG, onze privacy policy bijgewerkt. Om verder te kunnen gaan dien je eenmalig akkoord te gaan met de bijgewerkte privacy policy. Heb je vragen neem dan contact op met info@security.nl.

Verzenden
Privacy Policy

Op 24 mei 2018 hebben we, in het kader van de AVG, onze privacy policy bijgewerkt. Om verder te kunnen gaan dien je eenmalig akkoord te gaan met de bijgewerkte privacy policy. Heb je vragen neem dan contact op met info@security.nl.

Verzenden
Inloggen

Bedankt! Je kunt nu inloggen op je account.

Wachtwoord vergeten?
Nieuwe code captcha
Inloggen

Wachtwoord Vergeten

Wanneer je hieronder het e-mailadres van je account opgeeft wordt er een nieuwe activatielink naar je gestuurd. Deze link kun je gebruiken om een nieuw wachtwoord in te stellen.

Nieuwe code captcha
Stuur link

Password Reset

Wanneer je het juiste e-mailadres hebt opgegeven ontvang je automatisch een nieuwe activatielink. Deze link kan je gebruiken om een nieuw wachtwoord in te stellen.

Sluiten
Registreren bij Security.NL

Geef je e-mailadres op en kies een alias van maximaal 30 karakters.

Nieuwe code captcha
Verzenden

Registreren

Je hebt je succesvol aangemeld. Voordat je je account kunt gebruiken moet deze eerst geactiveerd worden. Dit kan je zelf doen middels de activatielink die naar het opgegeven e-mailadres is verstuurd.

Sluiten
Over Security.NL
Huisregels
Privacy Policy
Adverteren
© 2001-2020 Security.nl - The Security Council
RSS Twitter