Probleem
Klanten die transparante proxy gebruiken, moeten het verkeer actief decrypteren om een onderscheid te maken tussen YouTube.com en Google.com.
Omgeving
Transparent Proxy-toepassing, HTTPS-proxy ingeschakeld
Symptomen
Eerder gebruikte Google verschillende SSL-servercertificaten voor elk van hun primaire domeinnamen. Dus als u verbonden was met https://www.google.com en https://www.youtube.com, zou u verschillende servercertificaten zien, elk die specificeren dat ze geldig zijn voor één van die twee domeinen.
Onlangs is Google overgeschakeld op het gebruik van één SSL server certificaat voor al hun webeigenschappen, ondertekend door hun eigen interne CA. Als u dus naar de twee hierboven genoemde domeinen bladert met behulp van SSL, krijgt u hetzelfde certificaat. Dat certificaat gebruikt een uitbreiding naar X.509 genaamd "OnderwerpAltName" om een paar dozijn domeinen als geldig voor dat certificaat op te geven. Hieronder vindt u een volledige lijst met Google-domeinen die geldig zijn voor dit nieuwe certificaat.
Dit werkt fijn voor browsers: Je browser weet dat het probeert verbinding te maken met youtube.com, het ziet een certificaat dat geldig is voor youtube.com (en nog een dozijn andere dingen) en het laat de verbinding door gaan zonder waarschuwingen.
Hoe dit van invloed is op de WSA
Voor een proxy server is het eerste wat je moet doen als je een verzoek van een client ziet, het bepalen van de webbestemming van de client. Voor gewoon HTTP is het vrij makkelijk: Bekijk de Host header in het HTTP-verzoek.
Voor SSL is het moeilijker. In expliciete proxy-modus, vertelt de browser ons in het CONNECT-verzoek, zodat het gemakkelijk is. Het probleem doet zich voor in een transparante modus. Met decryptie die op WSA wordt geactiveerd, moeten we bepalen waar de gebruiker probeert te bladeren alvorens de verbinding daadwerkelijk te decrypteren.
Vandaag doen we dit door te kijken naar het IP-adres dat de klant probeert te verbinden, zelf met dat IP te verbinden, en naar het certificaat te kijken, in het bijzonder op het GN-veld. Dit werkt goed wanneer een unieke hostname zijn eigen SSL servercertificaat heeft. Het stelt klanten ook in staat om een beetje beleidshandhaving voor SSL-verkeer te implementeren zonder iets te decrypteren, en dus zonder de CA-cert van het WSA aan hun klanten uit te delen. Een klant kan https://www.google.com toestaan maar https://www.youtube.com blokkeren door de eerste in te stellen om "toe te staan, niet decrypteren" en de tweede om "te laten vallen" in het decryptiebeleid.
Nu dienen youtube.com en google.com hetzelfde servercertificaat op. Dit betekent dat WSA, om een onderscheid te maken tussen de twee, naar iets anders moet zoeken dan alleen het certificaat dat werd geserveerd op het IP-adres waar de klant probeert verbinding te maken.
De oplossing voor dit probleem wordt getraceerd als Cisco bug ID 74969.
Oplossing
Als u een configuratie hebt die door deze beïnvloedt, dan is de onmiddellijke oplossing om actieve decryptie van SSL verkeer aan te zetten. Voor klanten die het CA-certificaat nog niet eerder van de WSA hebben verspreid, zullen ze dit moeten doen. Dit is de beste algemene oplossing voor het probleem.
Bijlage
Lijst van domeinen waarvoor het nieuwe certificaat van Google geldig is:
DNS-naam: *.google.com
DNS-naam: google.com
DNS-naam: *.atggl.com
DNS-naam: *.youtube.com
DNS-naam: youtube.com
DNS-naam: *.ytimg.com
DNS-naam: *.google.com.br
DNS-naam: *.google.co.in
DNS-naam: *.google.es
DNS-naam: *.google.co.uk
DNS-naam: *.google.ca
DNS-naam: *.google.fr
DNS-naam: *.google.pt
DNS-naam: *.google.it
DNS-naam: *.google.de
DNS-naam: *.google.cl
DNS-naam: *.google.pl
DNS-naam: *.google.nl
DNS-naam: *.google.com.au
DNS-naam: *.google.co.jp
DNS-naam: *.google.hu
DNS-naam: *.google.com.mx
DNS-naam: *.google.com.ar
DNS-naam: *.google.com.co
DNS-naam: *.google.com.vn
DNS-naam: *.google.com.tr
DNS-naam: *.android.com
DNS-naam: *.googlecCommerce.com
Feedback