Waarom wil je dit?

Als je geen kwade bedoeling hebt, zou ik eens gaan kijken
bij SSL proxies. Als systeembeheerder is het afhankelijk van
de implementatie mogelijk de sessie plain text te sniffen.

Ik geef geen garanties over juridische aspecten.

Om een falende webservice-aanroep die over HTTPs gaat te
debuggen.



Zoals gezegd ben ik niet echt op zoek naar een
proxy/MitM-oplossing. Ik gebruik normaal gesproken al een
prachtige proxy-tool voor het debuggen van
webservice-aanroepen (WebScarab), maar in dit geval doet het
probleem zich vreemd genoeg wel voor bij een directe
aanroep, maar niet bij een aanroep die via WebScarab gaat.
Vandaar dat ik de directe aanroep wil kunnen analyseren, en
niet een die via een proxy verloopt (want blijkbaar is er
een relevant verschil).

Overigens werken veel proxy/mitm-tools in dit geval ook niet
omdat mijn kant zich met een client-certificaat moet
authenticeren. WebScarab ondersteunt dat overigens dus wel,
mooi spul hoor.



Dat verwacht ik ook niet van een anoniempje op een forum.

Vol;gens mij wil je niet de inhoud, maar de sessieopbouw
bekijken.

Kijk even naar een paar van de volgende zaken:

- Geeft de server foutmeldingen?
- Wordt de sessie goed opgebouwd, maar zie je geen verkeer?
- Wordt er goed omgegaan met cookies en certificaten (CA e.d.)?
- Wat is de netwerkopbouw:
- Firewalls
- Wordt er gebruik gemaakt van NAT of loadbalancing?
- MTU (Door encapsulatie kan een sessei niet goe opgebouwd
worden)

Met andere woorden creeer een compleet plaatje van de
situatie en ga daarvandaan 1 voor 1 wegstrepen.

Suc6

Om wat voor falende webservice-aanroep gaat het eigenlijk?

Volgens mij was SSL er juist voor dat tegen te gaan. Er was
iets met kuilen graven enzo :-)

Maar serieus: Het heeft misschien maar indirect met jou
vraag te maken, maar apache maakt aparte logs aan voor SSL
requests (of kan dat in ieder geval doen), misschien kan je
daar de informatie in vinden die je nodig hebt zonder de
inhoud van een SSL sessie te hoeven bekijken.

De sessieopbouw kon ik al zien met Wireshark. Daarmee zag ik
ook dat er data over de lijn die kant op ging na de
handshake, en er pas na de timeout weer data terug kwam. De
vraag was dus (onder andere) of ik een incomplete request
stuurde, of dat de andere kant onterecht bleef wachten. Daar
hoopte ik achter te komen door in de stream te kijken.

Deze keer ben ik er met de samenwerking van de mensen aan de
serverkant achter gekomen dat het probleem inderdaad bij hen
zat. De volgende keer zitten er misschien minder
hulpvaardige mensen aan de andere kant, dus ik ben nog
steeds erg geinsteresseerd in een tool om me te helpen de
zaken aan mijn kant nog beter en makkelijker te kunnen bekijken.

Het gaat om een SOAP-webservice die het met kleine
hoeveelheden aanroepen gewoon deed, maar na wat grotere
hoeveelheden snel achter elkaar (~100) dienst begon te weigeren.