[SSL/Sec/XML] Hoe herhalingsaanvraag voorkomen?

[r0bert]

Mijn specialisme is nu niet bepaald beveiliging, maar ik heb me er toe gezet. Ik geloof dat ik een redelijk ver ben gekomen met het opzetten van een soort beveiligde verbinding, wat bovenop HTTPS/TLS moet komen. Ik heb een XML bestand met verschillende keys:

http://dev.sove.nl/fw/req.xml

Maar nu is dat allemaal leuk en aardig, als iemand dit bestand in handen krijgt (ondanks https) dan zou deze droog de request opnieuw in kunnen dienen. Hoe voorkom ik dat? Nadat alles afgehandeld is kan ik het op een sessie locken, maar bij de eerst aanvraag snap ik dat niet helemaal?

In de standaards hebben ze het over 'nonce', een of andere random string die mee wordt gestuurd. Ik heb verschillende bronnen erover geraadpleegd, maar ik kan het niet veilig krijgen. Iemand die me kan helpen?


_{Ik heb zitten puzzelen met een datum/tijd variabele, maar omdat nu overal mee te gaan vermengen, lijkt me niet wenselijk? Daarnaast is het verzenden van een repeating request niet erg tijdrovend, dus lijkt me het lastig i.v.m. te snelle timeouts naar client toe?}

[ Voor 15% gewijzigd door r0bert op 05-11-2008 14:28 . Reden: URL, typo zie onder ]

[matthijsln]

Het is geen "nounce" maar "nonce", voor "number used once". Kijk hier eens: Wikipedia: Replay attack

[r0bert]

Dat zijn ook de dingen waar ik op uit kwam.

Bij de eerste (het sturen van de session id) moeten er 2 communicaties heen en terug plaatsvinden, ik zou het graag in één keer doen? Ik snap het principe ook niet echt, want als degene die aan het 'tappen' is, zijn request eerder bij de server krijgt, steelt deze de sessie, toch?

De toegevoegde waarde van MAC snap ik niet echt. Misschien omdat ik al signatures gebruik.

Het tijdstempel begrijp ik, maar ook dat snap ik niet. Want als ik een timeout van 10 seconden heb, dan heeft degene die 'tapt' toch tijd zat om binnen die tijd het request óók te sturen?

Bedankt voor de link in ieder geval alvast.

[ Voor 30% gewijzigd door r0bert op 05-11-2008 14:44 ]

[Voutloos]

r0bert schreef op woensdag 05 november 2008 @ 14:34:
Want als ik een timeout van 10 seconden heb, dan heeft degene die 'tapt' toch tijd zat om binnen die tijd het request óók te sturen?

Combineer met de nonce en voila?

[r0bert]

Kan ik zo'n nonce dan gebruiken met één enkele communicatie van client naar server (en terug)?

Zo staat het trouwens ook in de WSSE standaard. Username, passwd, nonce en created/timestamp.

[ Voor 36% gewijzigd door r0bert op 05-11-2008 15:08 ]

[latka]

In jouw geval (je signed de body) kun je alleen het complete request opnieuw indienen. Volgens mij is dit iets wat je zowiezo moet ondervangen in je applicatie omdat er ook valide scenarios zijn waarbij zo'n replay aan de orde is (bijvoorbeeld: timeout, je service is te traag en de consumer stuurt het request nogmaals uit, of als er een queueing mechanisme gebruikt wordt zal de queue het bericht opnieuw versturen).
Er zijn meerdere oplossingen hiervoor:
1) Uniek nummer meenemen en vastleggen
2) Interpreteren van het request en vaststellen dat de actie al uitgevoerd is.

Als je service idempotent is is het geen probleem (eigenlijk situatie 2).
Voor unieke nummers ken ik WS-Addressing die een message-id koppelt aan ieder request.

[r0bert]

WS-Addressing is inderdaad ook iets wat ik wil gaan implementeren, maar wou niet te grote stappen nemen. Als dat het probleem oplost, moet ik er toch maar mee aan de slag. Maar is dat eigenlijk niet hetzelfde als 'situatie 1'? Daarbij blijft het enige probleem, dat als de 'tapper' (heeft dat een naam?) het bericht onderschept en eerder naar de server stuurt, deze de sessie kaapt? Bij een dubbele aanvraag, kan ik direct de sessie dichtgooien, maar da's volgens mij een workaround en geen oplossing. Ik zie iets verkeerd denk ik met die nonce?

Zover als ik kan bedenken, wordt het altijd 'wie eerst komt, wie eerst (en enig) maalt'?

[ Voor 70% gewijzigd door r0bert op 05-11-2008 15:21 ]

[Voutloos]

r0bert schreef op woensdag 05 november 2008 @ 15:06:
Daarbij blijft het enige probleem, dat als de 'tapper' (heeft dat een naam?) het bericht onderschept en eerder naar de server stuurt, deze de sessie kaapt?

Dat is dan een Man in the Middle attack. SSL + controle crtificate chain moet reeds MitM kunnen voorkomen.

[r0bert]

Ok, maak ik ook daar even een diepere studie van. Certificaat mag toch wel public verstuurt worden? Of moet die ook geencrypt worden?

* gaat zelfstudie doen *

[ Voor 53% gewijzigd door r0bert op 05-11-2008 15:22 ]

[matthijsln]

r0bert schreef op woensdag 05 november 2008 @ 15:21:
Certificaat mag toch wel public verstuurt worden? Of moet die ook geencrypt worden?

Ja, want een certificaat is gewoon een public key welke is gesigned.

[r0bert]

Het is allemaal wel baringewikkeld, sommige links die ik bekijk... help. Respect voor degene die het wel allemaal snappen zeg.

matthijsln
Ja, want een certificaat is gewoon een public key welke is gesigned.

Thanks, in ieder geval iets waar ik zeker van kan zijn

Voutloos
Dat is dan een Man in the Middle attack. SSL + controle crtificate chain moet reeds MitM kunnen voorkomen.

Ik kan toch nooit:
- Voorkomen dat de MitM een replica van het request stuurt (eerder dan de client zelf, incl. timestamp & nonce)
- Weten of er nog (identieke) requests aankomen (evt het originele)
Zelfs met alle wikipedia pagina's open kan ik de oplossing nog niet vinden, volgens Wiki in de richting van PKI, maar dat gebruik ik toch al ?

Bedankt voor de (vlotte) hulp tot nu toe

[ Voor 10% gewijzigd door r0bert op 05-11-2008 15:58 ]

[Voutloos]

r0bert schreef op woensdag 05 november 2008 @ 15:40:
- Voorkomen dat de MitM een replica van het request stuurt

Nee, want dankzij de encrypte bij SSL snapt de MitM geen ene (*&^$$%@ van de bitjes die langskomen.

[r0bert]

Ok, ik heb mijn best gedaan

code:

CLIENT (send msg1 over http?)
> Stuurt unieke message id (uuid)
> Stuurt certificaat (base64)
> Stuurt username (plain)
  > Stuurt encrypted wachtwoord (md5 + public server key)
  > Stuurt timestamp (plain)
> Stuurt signature van (concat) met private client key:
  Hash (sha1) message id
+ Hash (sha1) concat username, password etc.
+ Hash (sha1) client certificaat
+ Hash (sha1) request body
> Stuurt request body (plain)


SERVER (response msg1 over https)
- Checkt of created + std. lifetime < huidige tijd/datum
- Checkt of message id uniek is (binnen bovenstaande lifetime)
- Slaat message id + timestamp + lifetime op.
- Checkt de rest, username, password, certificaat, signatures.
- (Verwijderd message id waarvan de lifetime sowieso verlopen is.)

> Stuurt 'related to message id' (uuid)
> Stuurt session id (voor verdere communicatie)
> Stuurt eigen certificaat (base64)
> Stuurt signature van (concat) met private server key:
  Hash 'related to message id'
+ Hash (sha1) session id
+ Hash (sha1) server certificaat
+ Hash (sha1) response body
> Stuurt response body (plain)

Is het zo compleet? Misschien zelfs overcompleet?

[ Voor 16% gewijzigd door r0bert op 05-11-2008 18:28 ]

[r0bert]

Mm, als ik de Reply-To van WS-Addressing sign met de private key van de client server, dan maakt het toch niet meer uit of een request 1 of 100 keer wordt verzonden, aangezien ik naar dezelfde server reply? Door de message id zal de response (danwel afkomstig van een MitM) altijd naar de juiste Reply-To worden gestuurd en slechts 1x gefactureerd worden. Of zit er ook nog een security-hole in het droog naar een Reply-To adres (domain) sturen?