Dan vraag ik me af waarmee die netwerkbeheerders bezig zijn....Gebrek
aan profecionele kennis? Iemand kan nog na porno sites maar kan je nog controleren met cookies en tijdelijke bestanden waar de gebruiker niet in mag komen. Ook al weet je het tijd stip niet kan je toch zo zien aan de dingen die zijn gedownload en wat er op de computer staat.

Mee eens... hoe vaak blijkt dat je SSH-tunnels e.d. over
port 443 kan opzetten... het is gewoon niet te
controleren... nu kan je wel SQUID-proxy gebruiken om in any
case er voor zorgen dat er loggin plaats vind.

Joh, meen je dat nou.

Tja, heb je de keuze tussen plain text over internet, of encrypted over
internet... Damned if you do, damned if you don't... Nou, dan lopen we denk
ik liever het risico dat er via HTTPS iets fout gaat dan via HTTP alles fout
gaat. Ja, het is een tikkende tijdbom, maar liever een tikkende tijdbom, dan
eentje die al afgaat op heup hoogte.

Logging lost niet alles op, bij het gebruik van een forwarding proxy waar
een HTTPS verbinding mee tot stand wordt gebracht is er weinig meer te
loggen. Als je wilt weten wat er gebeurt zal de verbinding opengebroken
moeten worden.

Bij netwerken met een vertrouwelijk karakter wordt HTTPS normaal niet
toegestaan. Juist om dit probleem te voorkomen. Een enkele keer wordt er
met een whitelist gewerkt van vertrouwde sites.

Indien dit toch wordt toegestaan wordt de HTTPS verbinding opengebroken
en gescand.

Er wordt wel over nagedacht maar niet door iedereen. ;-)

Dan vraag ik me af waarom er geen oplossing komt in een browser zelf.
Als het toch input/out put is. Is er vast wel een mogelijkheid bv via de
socket ofzo dat data nog een keer doorgelust kan worden na een logfile.

Lekker afblijven dan van die https maar bij de output van de browser iets te
lussen.

Dat is niet te vertrouwen, aangezien je niet zeker weet dat
het verkeer dat "gelust" wordt ook daadwerkelijk het verkeer
is dat over de HTTPS verbinding ging.

Gewoon SSL openbreken op de perimeter, scannen en weer encrypted
doorzetten naar de client. Niks aan, toch gescanned, en nog steeds
encrypted tussen server en client. Talloze doosjes kunnen dit.

wat hebben tikkende tijdbommen met plaatjes van naakte
vrouwen te maken?

Het was ook maar een simpel voorbeeld. Je kan ook een applicatie maken
die om de zoveeltijd een printscreen maakt bij vermoedens van dit soort
zaken. Heel simpel wat wel te vertrouwen is. Een gebruiker die dit niet
weet dat er zo screenshots gemaakt worden. Is een systeem beheerder
een stap voor. Een printscreen is maar 116kb en kost niet eens zoveel hardeschijf ruimte. Het enige wat je dan hoef te doen is te zorgen dat het niet in de software staat en het programma af te schermen van de gebruiker.

Zijn er geen firewalls die een "Man In The Middle" attack
doorvoeren op https verkeer om het toch te kunnen scannen?
de eind gebruiker checkt toch amper dat het certificaat
uitgegeven is van zijn werkgever ipv van die site owner :-)

Een legitieme MitM is niet al te ingewikkeld op te zetten.

"Werknemers kunnen hierdoor pornosites via HTTPs bezoeken of
vertrouwelijke informatie versturen zonder dat het bedrijf hier kennis van
heeft. "

Porno sites bezoeken is een ernstig vergrijp, dat heeft namelijk met sex te
maken en sex heeft met voortplanting te maken. Het wezen van het
bestaan van de mens. Mijn stelling is: Het is tegennatuurlijk en anti-
sociaal om te proberen sexualiteit uit te bannen. Het is overgewaaid uit de
VS en sinds Balkenende I hier klakkeloos overgenomen.

Je kunt ook vertrouwelijke informatie versturen via HTTP of SMTP. Hoe gaat
een werkgever dat ontdekken? Ik denk: niet of nauwelijks. Er gaan
gigabytes aan traffic over en weer en het enige zinnige dat geregistreerd
wordt (als je geluk hebt) zijn verkeersgegevens. Scannen op woorden zal
te veel false positives opleveren.

Het is onzin dat poort 443 vaker dan poort 80 wordt gebruikt door
aanvallers. Poort 80 wordt door vrijwel alle trojans gebruikt, op een
piepklein percentage na. Dat is ook logisch, de kans dat poort 80 open
staat is groter en het is makkelijker om gebruik te maken van bekende
paden.

Er zijn al lang proxies die HTTPS traffic kunnen scannen op bekende
malware en dat werkt via de man-in-the-middle methode. Daar gaat de
PDF over: reclame maken voor Webwasher.

Wat betreft tunneling: dat is nooit te voorkomen. Opdrachten en data
kunnen op een oneindig aantal manieren gecodeerd worden, en dat werkt
ook voor HTTP. Je kunt zelfs tunnelen via SMTP als je dat zou willen.

Je kunt *altijd* gegevens naar buiten brengen zonder dat ze te controleren
zijn. Zelfs met standaard coderingswijzen. Neem bijvoorbeeld UUencode.
Converteer een ZIP file naar een uue file met WinZIP. Verplaats de header
achter de data (of verwijder hem) en vrijwel geen scanner zal iets kwaads
ontdekken. De ontvanger kopieert de header terug, slaat het bestand op
als *.uue en opent het met WinZIP. Voila.

De stelling is fundamenteel ernstig fout omdat het ervan uitgaat dat de
alternatieven de gestelde beperkingen niet hebben en dat is niet zo.

Helemaal mee eens. En daarnaast moet op de end point (pc van
de gebruiker) ook een virusscanner zijn geinstalleerd. Dus:
Eens met de stelling wanneer de proxy niet goed wordt
toegepast en de pc van de gebruiker verder niet gecand
wordt, oneens wanneer de proxy wel goed wordt toegepast
en/of de pc van de gebruiker wel gescand wordt.

Totaal irreeel. Niemand kent hier de techniek?!

perimeter
security
is
niet
genoeg
.

Dat heeft verder niets met http versus https te maken, je
kunt alles over alles multiplexen en desnoods door elkaar
husselen om de stateful firewall in de war te gooien. Je
moet gewoon zorgen dat al je machines beveiligd zijn. En als
je niet wil dat je geen volledige controle over je
werknemers hebt, there's no such thing as an almost
universal network.

Sure, is alleen technology die nog niet echt voor het MKB beschikbaar is.
Om de Secure Computing spam te niveleren maar wat links bij
concurrenten:
http://www.bluecoat.com/downloads/whitepapers/BCS_SSL_wp.pdf
http://www.finjan.com/Content.aspx?id=184

Suc6 met lezen.. en bedenk goed wat jouw beheerder met die bijzondere
certificaten doet :-)

Future security architecture should be built around
deperimeterisation!

Oneens. Het verhoogde risico dat HTTPS verkeer met zich meeneemt is
eenvoudig te pareren door HOST beveiliging.

Alleen steunen op perimeter beveiliging is niet afdoende tegenwoordig.
Menig exploit maakt al gebruik van double of triple payload encryption
waarbij je een zeer sterke engine moet hebben om deze te decrypten in
zo'n tempo dat de gebruiker geen latency ervaart.

"man-in-the-middle" oplossingen klinken leuk, maar in een tijd dat
mensen gewend zijn aan supersnel Internet en latency onacceptabel is,
zijn die oplossingen meer leuke theorien dan uitvoerbaar op grote schaal.

Robin Toornstra

In de eerste zin lijken drie argumenten te staan, maar het
zijn er maar twee:
1 - HTTPS ... zorgt er namelijk voor dat vertrouwelijke
gegevens voor derden worden afgeschermd, ...
en dat verstuurde informatie niet door derden kan worden
bekeken of aangepast

2 - dat de identiteit van de partij waarmee de
informatie wordt uitgewisseld geverifieerd is

Maargoed. Ook over versleutelde verbindingen kan je allerlei
verkeer sturen. Moeten we het daarom maar niet meer gebruiken?
Proprietaire bestandsformaten zijn wellicht lastiger te
scannen, door wie of wat dan ook. Vanaf heden strictly
verboten om in e-mails dit soort bestanden mee te sturen?

En dan nog zoiets knulligs: Daarnaast is het mogelijk om
malware via HTTPs op systemen te krijgen zonder dat
virusscanners kunnen ingrijpen.
Ten eerste: als dat malwaretje uit de tunnel komt en lekker
aan de slag wil, dan grijpt een goede scanner(-combinatie)
op het slachtoffersysteem alsnog in?!
Ten tweede: Het ook versleuteld kunnen versturen van
malware, is toch niet de oorzaak van het enorme succes van
die malware?

Evenzogoed is alleen steunen op host based oplossingen ook niet
afdoende. Maar al te vaak hebben organisaties geen 100% controle over
de endpoint hardware. Denk aan zaken als VMWare, (externen met)
meegebrachte apparatuur, specialistische machines die niet door de
automatiseringsafdeling beheerd worden etc. etc.

Of de userexperience er onder lijdt hangt af van de gebruikte technologie.
URL-filtering zorgt nauwelijks voor latency, centrale virusscanning wat
meer.. Maar het is aan de organisatie om een keuze te maken tussen
userexperience enerzijds en de interiteit en vertrouwelijkheid van
informatie anderzijds. Verder is voor veel organisaties veel belangrijker
welke informatie de organisatie verlaat. Controle daarop is vooralsnog toch
beter centraal te regelen.

jongens ooit gehoord van vpn.!!!

Je kan ook gewoon een Blue Coat ProsySG er tussen zetten. Deze kan een
"nette" man in de middle uit voeren en zo doende al het HTTPS verkeer
onderscheppen en scannen.

Volgens mij weet ik het het! Hoe heet dat nr ook al weer ohja sex bomb sex
bomb your my sex bomb , Give it to me baby when you need to come
along, sex bom sex bomb ...

Zou een (Squid) proxy inrichten waarbij HTTPS geblokt wordt, maar m.b.v
een whitelist enkele HTTPS sites wel kunnen worden benaderd.
Dit is voor de meeste organisaties toereikend.
Natuurlijk kun je het HTTPS-verkeer inhoudelijk hiermee nog niet
controleren.

Mee eens. Ik bedoel dan ook dat je alleen door op meerdere locaties
(perimeter, host, core) en met verschillende technieken (url scanning, anti-
viri, ips, fw, etc, ssl proxy) je data goed kunt beschermen.

Alsof een gemiddelde werknemer ook daadwerkelijk het verschil tussen
http en https weet, laat staan dat hij dan snapt dat je met https naar porno
sites kan gaan.

Kan je het https verkeer niet opvangen met een snifer?

Ja dat kan, het is alleen versleuteld, dus heb je er weinig aan

Als https niet op de border geterminated word heb je als organisatie een
ander probleem, namelijk GEEN enkele vorm van informatiebeveiliging.

Verder valt het mij op dat je bij vele organisaties rechtstreeks kunt
connecten naar een website zonder dat er iets in de weg staat.

Ach, dat het verkeer naar mijn bank versleuteld is, vind ik
wel prettig.

En als een medewerker porno surft over een https site hebben
we daar een mooie security policy voor die het
arbeidscontract aanzienlijk kan verkorten.

OffTopic:
Toch mooi om te zien hoe men zich druk maakt om
netwerkvervuiling maar 10 jaar eerder kunnen sterven door de
stoflongen die zij oplopen in de gebouwen langs de
snelwegens in NL...........

Dit kan allemaal wel zijn, maar ze vertellen daarbij nergens
dat je ook alle browsers moet aanpassen om overal het
kwaadaardige self-signed proxy certificaat te installeren.
Je moet er voornamelijk goed bij nadenken welke issues je
echt wilt oplossen en welke je wilt gaan realiseren door dit
soort constructies!

Dat hoeven geen self signed certificates te zijn. Gewoon een
certificaat aanschafen die vertrouwd wordt en die
foutmelding ben je kwijt. Wat ook kan, dan wordt het een
echte mitm, is het on the fly genereren van een 'corect'
certificaat. Dan zie je als eindgebruiker niets meer.

Ik vind het openbreken van SSL en werken met fake
certificaten een slechte oplossing. Zo werk je natuurlijk
weer phishing in de hand omdat mensen geen flauw benul
hebben als ze een verkeerd certificaat voorgeschoteld
krijgen. De vraag of je op je werk moet gaan zitten
bankieren e.d. is een andere, maar het gebeurt (in mijn
geval iig wel).

Een ssl verbinding moet vertrouwd zijn, punt. Dat moet je
niet gaan ondermijnen met rare kunstgrepen. Het idee alleen
al dat een systeembeheerder mijn gmail wachtwoord voorbij
ziet komen doet me huiveren.

Het enige argument dat je in ssl verkeer zou willen kijken
lijkt porno te zijn. Als je je personeel zo graag wilt
betuttelen, ga dan af en toe eens stiekem achter ze staan om
te zien wat ze doen. :-) Virussen kun je volgens mij
namelijk prima op de werkstations scannen. Gevoelige
informatie komt ook via andere kanalen naar buiten.

SSL is geen tikkende tijdbom. Nieuwe stelling: straks is
alles HTTPS? :-)

Volgens mij ligt de kern van het probleem hierin: neem geen
snoepgoed van vreemde mannetjes aan.

Met de bluecoat en een ssl accelerator kaart kan men scannen in de ssl
tunnel : http://www.bluecoat.com/news/releases/2005/110805_ssl.html
...

aaah, ik zie het net een paar reply's hier boven staan, tis inderdaad niet
gratis...

Porno is niet zozeer een probleem, veel daarvan kan je met een beleid voor
Internet gebruik afdekken. Een analyse van opgevraagde URL's levert al
veel op. Daarin is meestal ook te zien of iemand van een externe proxy
gebruik maakt.

Een ander probleem zijn de 'phising' sites die meer dan alleen phisisng
zijn en ook lokaal dingen installeren. Veel virusscanners zien dit spul niet
of nauwelijks. Malware scanners zijn er beter in maar zien ook niet alles.

Bij gebruik van SSL wordt de bescherming op de PC van de gebruiker
gedaan. Dat betekent dat alle andere lagen weg zijn. Dat is de reden om
een SSL tunnel in een bedrijf open te breken en te controleren. Je scanner
zal dan iets beter moeten zijn dan gebruikelijk. Voor het prive gebruik van
een bedrijfsinternet voorziening dienen dan wel afspraken gemaakt te
worden.

https gebruik je in de meeste gevallen toch maar even? Dan moet je weten
wanneer iemand er gebruik van maakt en in die korte tijd moet je nog iets
uithalen.

en niet te vergeten, er naar toe in hun koekblikken...

Je krijgt in de eerste situatie een foutmelding in de
browser dat het certificaat niet correspondeert met de
geraadpleegde website. Dit werkt dan niet.

Het tweede geval is wel mogelijk, maar dan moet het bedrijf
een valide intermediate root certificaat hebben (door een
echte CA uitgegeven) waarmee zelf gegenereerde certificaten
ondertekend kunnen worden, of het bedrijf moet zelf voor CA
spelen en in iedere browser zijn eigen root certificaat van
te voren installeren. Zeker als dit certificaat dezelfde
namen gebruikt als in een door een echte CA uitgegeven root
certificaat.
De foutmelding verschijnt dan niet. Dit is dan een geslaagde
man-in-the-middle attack.
Alleen een zeer slimme gebruiker kan erachter komen en het
valse root certificaat verwijderen waarna de foutmelding
zoals in situatie 1 beschreven weer verschijnt.