[JAVA SSL] Controleren of een verbinding veilig is

[Bladerer]

Dames/ Heren

Ik weet niet precies of dit het juiste onderdeel van het forum is om deze vraag te stellen, maar ik waag het er maar op. Voor het koppelen van ons Backoffice systeem met een ASP in de VS is gekozen voor Webservice integratie.

Deze verbinding is bewerkstelligd in JAVA d.m.v. AXIS 1.1 in combinatie met .NET aan de ASP kant. Voorheen verliep alle communicatie onbeveiligd, maar hier moet op korte termijn een einde aan komen.

Momenteel hebben we SSL proberen te implementeren door de volgende code toe te voegen aan onze reeds bestaande AXIS code:

code:

System.setProperty("javax.net.ssl.trustStorePassword", "changeit");
System.setProperty("javax.net.ssl.trustStore","c:/mijncert.ks");
System.setProperty("java.protocol.handler.pkgs" , 
"com.sun.net.ssl.internal.www.protocol");
java.security.Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());

Tevens is het call adres verandert van http naar https. Zonder de bovenstaande code maar met de verandering van het adres alleen werkte het niet. AXIS liet ons dan netjes weten dat het SSL protocol niet werdt begrepen.

Na de installadtie van JSSE en de bovenstaande code kregen we echter geen fouten meer.
Voegden we alleen de SSL provider en de Security.addProvider toe aan de code en lieten we de keystore code weg, dan werkte de client ook, hoe kan dat zonder certificaat? accepteert AXIS dan gewoon het server certifikaat?

De vraag is nu echter of de verbinding wel ECHT 100% SSL beveiligd is. Door gebruik te maken van een pakket sniffer hebben we getracht te kijken of we de xml berichten konden onderscheppen.

Het enige dat we echter zagen waren pakketje van +- 6 KB ieder van een onleesbaar formaat en een niet kloppende checksum.

Betekent dit nu dat de verbinding idd via SSL verloopt en dus veliger is dan zonder SSL?

[Verwijderd]

Bladerer schreef op 14 augustus 2004 @ 17:36:
Tevens is het call adres verandert van http naar https. Zonder de bovenstaande code maar met de verandering van het adres alleen werkte het niet. AXIS liet ons dan netjes weten dat het SSL protocol niet werdt begrepen.

Na de installadtie van JSSE en de bovenstaande code kregen we echter geen fouten meer.
Voegden we alleen de SSL provider en de Security.addProvider toe aan de code en lieten we de keystore code weg, dan werkte de client ook, hoe kan dat zonder certificaat? accepteert AXIS dan gewoon het server certifikaat?

De vraag is nu echter of de verbinding wel ECHT 100% SSL beveiligd is. Door gebruik te maken van een pakket sniffer hebben we getracht te kijken of we de xml berichten konden onderscheppen.

https gaat normaal gesproken over poort 443 (als ik me niet vergis) en http over poort 80.

Go figure...

[Bladerer]

Als ik me niet vergis zag ik poortnummers in de range 9000 voorbij komen.
SSL is natuurlijk op de webserver zo in te stellen dat het gebruik maakt van een door jou gedefineerd poortnummer. Voor zover ik mij kan herrinneren zag ik namelijk geen poort nummer 443 langs komen.

[Verwijderd]

Bladerer schreef op 15 augustus 2004 @ 14:26:
Als ik me niet vergis zag ik poortnummers in de range 9000 voorbij komen.
SSL is natuurlijk op de webserver zo in te stellen dat het gebruik maakt van een door jou gedefineerd poortnummer. Voor zover ik mij kan herrinneren zag ik namelijk geen poort nummer 443 langs komen.

AXIS ken ik niet, maar het lijkt erop dat je de vrije hand hebt in het configureren van je server
Je bepaalt dan toch zelf op welke poort je SSL laat draaien, dus dat zou je moeten weten. En als je XML files over de lijn stuurt, en je ziet met een packet sniffer alleen maar prut, dan lijkt het erop dat SSL werkt. Kun je niet bv SSL uitzetten, en kijken of je de inhoud van je files die over de lijn gaan gewoon uit kunt lezen???
Voorzover mijn kennis reikt, is er of sprake van http verkeer dat iedereen dus uit kan lezen, OF het is SSL encrypted. Een tussenweg is er niet...

[Bladerer]

De optie om SSL weer uit te schakelen heb ik nog niet bewandelt.
Dit ga ik morgen eerst proberen. De server beheer ik niet zelf, deze wordt beheerd en ontwikkeld door de ASP (Application Service Provider). Ik beredeneerde echter puur hypothetisch dat het misschien mogelijk zou zijn dat ik niet kon afgaan op de poort 443 als de standaard SSL poort.

Ik vroeg mij alleen af of ik aan bepaalde pakket informatie in een oogopslag kon zien of de verbuinding wel veilig was.
Mogelijk zijn er hier mensen die weten dat als bv. de Checksum niet klopt of het bericht altijd 6KB groot is het om een SSL verbinding gaat.

Deze vraag staat nog altijd open!!

[ Voor 31% gewijzigd door Bladerer op 15-08-2004 17:09 ]

[Verwijderd]

Kun je de ASP niet laten instellen op de server dat er alleen SSL verbindingen toegestaan zijn?

Over de keystore:
volgens mij maakt de server gebruik van een certificaat signed door Verisign o.i.d.. Deze worden toch standaard door Java geaccepteerd? Alleen met eigen (root/CA) certificaten heb je de gegevens uit de keystore nodig volgens mij.

[ Voor 7% gewijzigd door Verwijderd op 16-08-2004 12:05 ]

[Bladerer]

Er wordt geen gebruik gemaakt van self-signed certificaten. Ze zijn idd uitgegeven door Verisign. De ASP heeft echter aangegeven dat we wel gebruik moesten maken van de certificaten. Zonder deze cer files werkte het echter ook al, dit is nu dus verklaard volgens selfemployed.