TLS en IPsec

[djwice]

Hoi,

Ik heb een newbie vraag op netwerk security niveau voor internet communicatie beveiliging.

Vraag
Is het mogelijk een IPSec Transport Encryptie verbinding op te zetten tussen de browser en de applicatie (door de proxy heen) en tegelijk een TLS tussen browser en proxy.

Situatie
We hebben een proxy die de TLS offload doet van het REST service verkeer dat van webbrowsers af komt.
Achter deze proxy zitten applicaties die de data verwerken.
De applicaties zijn stateless.

Doel
De headers nodig voor routing zijn bekend in de proxy, maar de rest niet. De rest is wel beschikbaar voor de inbrowser applicatie en onze server applicatie.

Dat onze servers de encryptie methoden bepalen (om snel onveilige te kunnen deactiveren). En gebruik kunnen maken van de meest moderne keys. Die elk bezoek anders zijn.

[ Voor 61% gewijzigd door djwice op 18-06-2016 11:31 ]

[CyBeR]

Nee. IPSec moet op host-niveau ingesteld worden. Je kunt dat niet vanuit de browser doen.

De geeigende manier overigens om met load balancers TLS te doen is door je load balancer de TLS te laten doen en dan plaintext met de server te praten. Als dat over een onveilig netwerk gaat zou je wel IPSec tussen je LB en je servers kunnen instellen, als je load balancer dat ondersteunt.

[_-= Erikje =-_]

Dat, over het algemeen is achter je lb een trusted intern netwerk, eventueel zou je daar alsnog tls kunnen doen zodat je lb effectief een soort mitm is. Aan de buitenkant kun je hoe dan ook de encryptie richting je clients bepalen op je lb

[djwice]

_-= Erikje =-_ schreef op zaterdag 18 juni 2016 @ 14:20:
Dat, over het algemeen is achter je lb een trusted intern netwerk, eventueel zou je daar alsnog tls kunnen doen zodat je lb effectief een soort mitm is. Aan de buitenkant kun je hoe dan ook de encryptie richting je clients bepalen op je lb

De Load Ballancer zit bij ons in de proxy, en de wens is dat dát component de data niet kan zien, maar wel de routering kan doen.

Eigenschap van TLS is dat ook de headers en het path encrypt. Welke nodig zijn voor de routing. SNI zorgd gelukkig wel dat we domain het domein weten, maar dat is voor routering op API niveau (path + methode) niet voldoende.

[ Voor 22% gewijzigd door djwice op 18-06-2016 18:40 ]

[johnkeates]

djwice schreef op zaterdag 18 juni 2016 @ 18:28:
[...]

De Load Ballancer zit bij ons in de proxy, en we willen dus juist dat dat component de data niet kan zien, maar wel de routering kan doen.

Dat kan niet.

[djwice]

johnkeates schreef op zaterdag 18 juni 2016 @ 18:32:
[...]

Dat kan niet.

Collega's roepen payload encryption als alternatief. Het uitwisselen van de sleutel die elke keer wijzigd + stateless server en niet door proxy te lezen, lijkt mij een uitdaging.

Ik dacht je moet bijna een TLS vergelijkbare handshake opzetten voor de payload om dat mogelijk te maken, maar dan tussen browser en applicatie terwijl de proxy al een verbinding heeft met de browser met TLS.

Klinkt bijna als een nieuw protocol op de bestaande lagen toevoegen..

[djwice]

CyBeR schreef op zaterdag 18 juni 2016 @ 12:43:
Nee. IPSec moet op host-niveau ingesteld worden. Je kunt dat niet vanuit de browser doen.

De geeigende manier overigens om met load balancers TLS te doen is door je load balancer de TLS te laten doen en dan plaintext met de server te praten. Als dat over een onveilig netwerk gaat zou je wel IPSec tussen je LB en je servers kunnen instellen, als je load balancer dat ondersteunt.

Thanks! Jammer, had mooi geweest. Ik ben een beetje huiverig voor payload encryptie op applicatie niveau. - de complexiteit voor API afnemers, sleutel uitwisseling en zorgen dat alle afnemers de modernste algoritmes gebruiken.

[johnkeates]

Het probleem is dat je informatie over de payload nodig hebt om te routeren, voor zowel de proxy als HA is dat nodig.

IPSec tussen hosts kan, maar alleen op host niveau. Daar binnen kan je dan wel weer TLS gebruiken. TLS kan je termineren op je frontend, maar je frontend kan intern dan wel weer een nieuwe TLS verbinding naar achterliggende hosts gebruiken voor de rest van het transport.

Stel dat het niet over het verkeer gaat maar over de data (de payload IN je payload dus), dan kan je beter AES op de data gebruiken, en die in een protocol gebruiken dat op zijn beurt weer in TLS geduwd wordt en weer met hosts communiceert in een IPSec sessie.

Waarom je dat allemaal zou willen doen is weer een andere zaak... wat probeer je te bereiken? Op het moment lijk je naar een oplossing te zoeken voor het verkeerde probleem.

[djwice]

johnkeates schreef op zaterdag 18 juni 2016 @ 19:16:
Waarom je dat allemaal zou willen doen is weer een andere zaak... wat probeer je te bereiken? Op het moment lijk je naar een oplossing te zoeken voor het verkeerde probleem.

De wens voor E2E encryptie van de data, waarbij E=browser en E=stateless applicatie (en anders om) is welke gevraagd wordt.

En we uiteraard niet voor elke API een apart sub-domein willen.

Dan kom je op payload in payload met ons time encryptie met elliptische algoritmes etc. en dat wordt best lastig om de key voor decryptie bij de andere partij te krijgen, zonder dat de TLS offloader die ook kan zien.

Het beeld is dat zelfs binnen ons eigen platform er geen vertrouwen mag zijn tussen twee lagen (ook al gebruiken die versleutelde communicatie onderling) omdat de data dan op 3 plekken, of meer, onversleuteld aanwezig is geweest (browser, service en er tussen), en dus ook daar onderschept kan worden.

De angst hiervoor is ontstaan omdat de wens is dat we gebruik maken van infrastructuur die beheerd wordt door derde partijen.
En omdat men denkt dat concurrenten dit ook doen voor al hun Traffic.

[ Voor 54% gewijzigd door djwice op 18-06-2016 20:38 ]

[johnkeates]

djwice schreef op zaterdag 18 juni 2016 @ 20:00:
[...]
De wens voor E2E encryptie van de data, waarbij E=browser en E=stateless applicatie (en anders om) is welke gevraagd wordt.

En we uiteraard niet voor elke API een apart sub-domein willen.

Dan kom je op payload in payload met ons time encryptie met elliptische algoritmes etc. en dat wordt best lastig om de key voor decryptie bij de andere partij te krijgen, zonder dat de TLS offloader die ook kan zien.

Het beeld is dat zelfs binnen ons eigen platform er geen vertrouwen mag zijn tussen twee lagen (ook al gebruiken die versleutelde communicatie onderling) omdat de data dan op 3 plekken, of meer, onversleuteld aanwezig is geweest (browser, service en er tussen), en dus ook daar onderschept kan worden.

De angst hiervoor is ontstaan omdat de wens is dat we gebruik maken van infrastructuur die beheerd wordt door derde partijen.
En omdat men denkt dat concurrenten dit ook doen voor al hun Traffic.

Dat kan je niet afdekken. Je kan op z'n best alleen gecertificeerde partijen gebruiken om de boel te hosten ofzo, maar dat is het dan ook wel.

Als je namelijk vind dat een derde partij nooit te vertrouwen is, is wat encryptie in je software gooien niet genoeg, want in theorie kan de software gewoon aangepast worden. Dus dan heb je behalve codering ook integriteit nodig, en kom je met systemen die geen keys mogen bevatten om dat die met DMA attacks uitgelezen kunnen worden.

Het hele concept dat de data in de browser niet encrypted is maakt het verhaal ook nogaal zinloos, juist daar is het erg makkelijk om aan te vallen. Naast TLS is er dan weinig qua 'beveiliging' toe te voegen. In-browser AES of ECDSA moet je ook niet willen, en plugins zijn dan ook weer niet perse wenselijk om het mee te doen, dus eigenlijk kan je vooraf al wel stellen dat je naast 'gewone' TLS het toevoegen van extra laagjes net zo goed weg kan laten. Meer van hetzelfde doen (dus, meer laagjes) maakt het niet veiliger als alles over hetzelfde pad gaat.

Als de data echt zo 'belangrijk' is kan je het beter gewoon helemaal niet via een browser doen, of, HTTP in z'n geheel. Dan kom je bij native apps, die ook nog eens geen OS-standaard crypto gebruikt, maar een 3rd party implementatie met extra strenge eisen. Keys in RAM is dan ook not-done, dus die moet je in CPU registers opslaan zodat ze niet met coldboot of DMA attacks te lezen zijn (maar wel door lokale software die draait op de machine en kernel-toegang heeft en dus CPU registers kan uitlezen).

Kortom: alles wat je wil, en dan ook nog eens op een third party 'niet betrouwbare' infra gaat A heel complex en duur worden, en B nagenoeg niks toevoegen boven op standaard HTTP-over-TLS.

[djwice]

johnkeates schreef op zaterdag 18 juni 2016 @ 21:48:
[...]


Dat kan je niet afdekken. ...

Kortom: alles wat je wil, en dan ook nog eens op een third party 'niet betrouwbare' infra gaat A heel complex en duur worden, en B nagenoeg niks toevoegen boven op standaard HTTP-over-TLS.

Thanks, dit was ook mijn beeld, het is helaas heel lastig dit te laten landen in de organisatie.

Ik zie dat Chrome nu een payload encryption heeft voor push messages : https://developers.google...16/03/web-push-encryption

Dit is wel private/public dus de proxy kan alleen een ander bericht maken, niet het bericht lezen, toch?
Die base64 verzwakt dat niet de encryptie? Door een sterke reductie van het aantal mogelijke tekens?

[ Voor 48% gewijzigd door djwice op 18-06-2016 22:30 ]

[johnkeates]

djwice schreef op zaterdag 18 juni 2016 @ 22:07:
[...]
Thanks, dit was ook mijn beeld, het is helaas heel lastig dit te laten landen in de organisatie.

Ik zie dat Chrome nu een payload encryption heeft voor push messages : https://developers.google...16/03/web-push-encryption

Die key gaat in mijn situatie nog steeds plain door de proxy toch? En de decryption key is gelijk aan description key, toch? Dus is er 0 extra veiligheid (beetje vertraging max.) en met die base64 verzwakken we de encrypted message door reductie van het aantal verschillende tekens.

Dat voegt inderdaad geen extra veiligheid toe.

Je kan je beveiliging tot aan de frontend goed voor elkaar krijgen, dat is het grote probleem hier niet, het is de laatste stap naar de browser waarbij het gewoon niet gaat werken. Zodra dat opgelost is is het prima te implementeren, maar om dat op te lossen moet je de browser vervangen, HTTP vervangen en dus eigenlijk het hele web-idee laten vallen. Als alternatief had je nog Java-Applets en daar voor ActiveX-applets, maar dat kan nu echt niet meer, net als dat Flash geen oplossing kan bieden. Zelf een plugin maken kan natuurlijk, maar dan moeten alle bezoekers die installeren, en dat gaat waarschijnlijk alleen in een gesloten commercieel b2b systeem werken, niet in iets voor 'het grote publiek'.

[ Voor 33% gewijzigd door johnkeates op 18-06-2016 22:34 ]

[djwice]

johnkeates schreef op zaterdag 18 juni 2016 @ 22:30:
[...]


Dat voegt inderdaad geen extra veiligheid toe.

Je kan je beveiliging tot aan de frontend goed voor elkaar krijgen, dat is het grote probleem hier niet, het is de laatste stap naar de browser waarbij het gewoon niet gaat werken. Zodra dat opgelost is is het prima te implementeren, maar om dat op te lossen moet je de browser vervangen, HTTP vervangen en dus eigenlijk het hele web-idee laten vallen. Als alternatief had je nog Java-Applets en daar voor ActiveX-applets, maar dat kan nu echt niet meer, net als dat Flash geen oplossing kan bieden. Zelf een plugin maken kan natuurlijk, maar dan moeten alle bezoekers die installeren, en dat gaat waarschijnlijk alleen in een gesloten commercieel b2b systeem werken, niet in iets voor 'het grote publiek'.

Maar als we het gebruik van een browser zien als een risico dat de klant wil lopen, zou de extra payload encryptie conform model Google (link) wel toegevoegde waarde hebben als we de beheerder van de proxy niet vertrouwen.

De payload encryptie van push messages wordt nu door 32% van de bezoekers ondersteunt in hun browser (Firefox 44+, Chrome 50+).

[ Voor 8% gewijzigd door djwice op 18-06-2016 23:53 ]