Het certificaat met de hand even controleren. Je ziet snel genoeg of daar rare dingen in staan. Uiteraard ook er voor zorgen dat de CA en SSL certificaten op recovation gecheckt worden. In de oudere (IE) platformen stond CRL check voor SSL standaard uit. En ook belangrijk; niet zomaar alle waarschuwingen in je browser op Ja/Yes/OK klikken. Lezen wat er staat en wanneer niet zeker, niet doorgaan

Alles alle SSL certificaten die je in je browser ziet gesigned (Issued By) zijn door dezelfde organisatie, en deze organisatie is geen bekende grote CA dan is er een grote kans dat je bedrijfproxy SSL MitM doet.

Met "alle SSL certificaten die je in je browser ziet" bedoelt Anoniem niet de root certificaten die in je browser geinstalleerd zijn; de praktijk is dat bedrijven en organisaties met MiTM oplossingen (die bijv. kwaadaardige scripts/flash/pdf scannen) 1 extra root certificaat aan de aanwezige root certs in je webbrowser toevoegen. De private key (behorend bij de public key in dat certificaat) bevindt zich in de toegepaste security appliance, en die wordt gebruikt om on the fly een certificaat van de site die jij bezoekt te na te maken en naar jouw browser te sturen.

M.a.w. als je het certificaat van die site bekijkt zal de CA (die het cerificaat digitaal heeft ondertekend) niet de "normale" zijn (Verisign, Thawte etc.) maar iets van de gebruikte security appliance; de overige gegevens uit het oorspronkelijke certificaat zullen meestal allemaal worden overgenomen (daarop checken heeft dus geen zin).

Wat Anoniem wel bedoelt is dat je naar verschillende SSL-beveiligde sites surft en elke keer kijkt of de CA hetzelfde is en "van een vaag merk". Zo ja dan is de verbinding ergens onderweg gemanipuleerd. Probleem: er is minstens 1 geval bekend waarbij een gerenommeerde CA intermediate certificaten voor installatie in dit soort MiTM crack-appliances installeert (zie http://www.security.nl/artikel/32871/1/SSL_niet_bestand_tegen_afluisteren_overheid.html). In dat geval wordt er door de certifcate chain verwezen naar een wel bekende (maar wel erg onbetrouwbare) root CA en geeft deze methode dus geen uitsluitsel.

Alternatief: als je bijv. portable Firefox kunt (en mag) draaien (of evt. een commandline app als curl), beiden natuurlijk met hun eigen root-CA set (niet "vervuild" met root certificaten van onbetrouwbare CA's), kun je checken of je van de site waarin je geinteresseerd bent hetzelfde server certificaat krijgt (lees: ondertekend door dezelfde CA) als in de voorgeschreven webbrowser; is dit een andere ga dan maar uit van MiTM (al dan niet met goede bedoelingen).

Kaspersky Internet Security kan tegenwoordig ook SSL openbreken en pakketten scannen (op je PC dus, maar voordat die pakketten je webbrowser bereiken), ook in dat geval moet je meen ik een Kasperski root cert in je browser installeren om foutmeldingen te voorkomen (zie bijv. http://support.kaspersky.com/kis2009/av?qid=208279764). Zelf heb ik er nog niet mee gespeeld, heeft iemand hier ervaring mee?

Maar elk SSL certificaat heeft toch een URL (al dan niet met wildcard) en een Owner? Deze combo, gekoppeld aan de fingerprint zijn toch uniek? Uit het verhaal van bitwiper maak ik op dat een proxyoplossing certs kan genereren, maar nemen deze dan ook bovenstaande credentials over? Zo ja, hoe kan dit dan een valide certificaat zijn? Of geldt het in dat geval alleen voor het zelf toegevoegde root cert van de proxyleverancier, en kun je fake SSL verbindingen dus herkennen aan het feit dat de CA overal hetzelfde is?

Bedankt Bitwiper, dat bedoelde ik inderdaad. :-)

@Anoniem van 15:23: hoe dit werkt beschrijf ik in m'n bijdrage van 27-03-2010, 00:31 in http://www.security.nl/artikel/32871/1/SSL_niet_bestand_tegen_afluisteren_overheid.html.

Een kleine achtergrond op het gebied van SSL.
Je hebt 1-zijdige SSL en 2-zijdige SSL.

De 1-zijdige SSL is de situatie waarbij de server beschikt over een SSL certificaat. In dit geval is de server dom, en gaat er vanuit dat de gebruiker is die die zegt dat ie is, zonder echt bewijs. Dit type SSL verbinding, via een proxy of direct met de doelserver, is absoluut gevoelig voor de door jou omschreven MitM.

De 2-zijdige SSL/TLS is de situatie waarbij zowel server als client beschikken over een geldig/vertrouwd SSL certificaat. In dit geval is er sprake van mutual authentication. In dit geval is geen MitM mogelijk, indien client certificaten door de doelserver/proxy worden afgedwongen.
Deze client certificaten kan je commercieel kopen van de bekende partijen, of zelf maken via OpenSSL, of verkrijgen via een hybride oplossing. Meer info op:
https://secure.wikimedia.org/wikipedia/en/wiki/Two-factor_authentication#Digital_Certificates
https://secure.wikimedia.org/wikipedia/en/wiki/Public_key_infrastructure

Detecteren van een MitM is lastig. Meestal heb je al een handeling uitgevoerd waardoor de MitM mogelijk werd, bijvoorbeeld door een fout server certificaat te vertrouwen. In dit geval kan je het server SSL certificaat uitlezen door bijv op het slotje te dubbel klikken in je browser.

@Mike1974
Ik neem aan dat gewone HTTPS websites onder 1-zijdige SSL vallen (of zorgen de standaard browser certs ervoor dat dit toch tweezijdig wordt)?

Correct.
Gewone HTTPS sites vallen onder 1-zijdige SSL.

Zodra de HTTPS site een client certificaat verplicht wordt het effectief een 2-zijdige SSL.
Dit is meestal eenvoudig af te dwingen door in IIS certificaten te verplichten, of ook in bijvoorbeeld in Apache zie:
http://www.impetus.us/~rjmooney/projects/misc/clientcertauth.html
http://blogs.iis.net/webtopics/archive/2010/04/27/configuring-many-to-one-client-certificate-mappings-for-iis-7-7-5.aspx