Computerbeveiliging - Hoe je bad guys buiten de deur houdt

Secure security.nl Onveilige verbinding

23-10-2011, 20:01 door Anoniem, 1 reacties
Beste mensen van Security.nl,

Hier op de website van security.nl bieden ze een secure website van security aan, hier bij zou je een veilige verbinding moeten hebben met de server.

http://img696.imageshack.us/img696/5019/79385612.png


Het vreemde is alleen dat als ik dus naar de website toe ga met mijn browser (Opera 11.52) zie ik tot mijn verbazing "Onveilige verbinding" met als uitgebreide tekst:

http://img508.imageshack.us/img508/5585/71124031.png

Niet beveiligde site

De verbinding met secure.security.nl is niet beveiligd, en moet niet worden gebruikt om gevoelige informatie uit te wisselen.

De volgende problemen zijn aanwezig:

De server ondersteunt beveiligde TLS-heronderhandeling niet. De sitebeheerder zou de server moeten bijwerken.

Het vreemde is dat als ik de website benader met IE 9 dat ik geen probleem ondervind met de website en hij zegt dat deze server versleuteld is.

http://img543.imageshack.us/img543/5750/53254536.png


Weten jullie wat dit is?
Reacties (1)
24-10-2011, 19:11 door Erik van Straten
Door Anoniem: Beste mensen van Security.nl,
Daar hoor ik niet bij maar ik ben wel een geïnteresseerde bezoeker ;)
De server ondersteunt beveiligde TLS-heronderhandeling niet. De sitebeheerder zou de server moeten bijwerken.
Dat meldt https://www.ssllabs.com/ssldb/analyze.html?d=secure.security.nl ook - alhoewel secure.security.nl verder een hoge score haalt (vulnerable voor de BEAST attack is geen ramp, dat is bijna elke https server).

Dat de server geen "secure renegotiation" ondersteund wil niet zeggen dat deze onveilig is; de mogelijkheid voor renegotiation kan geheel zijn uitgeschakeld. Uit http://blog.ivanristic.com/2010/10/disabling-ssl-renegotiation-is-a-crutch-not-a-fix.html:
Door Ivan Risti?: [...]
If disabling renegotiation prevents exploitation, that's surely a good thing? Well, it depends on how you look at things. Try to look at the problem through the eyes of a browser developer. I was actually prompted to write about this problem by Yngve Nysæter Pettersen, who's part of Opera's security group. Opera wants to protect its users, and for that to be possible they need to know if a particular server supports secure renegotiation. If a server does, Opera can happily renegotiate whenever necessary. But if a server does not support secure renegotiation, you can make an argument that Opera should refuse any renegotiation attempts.

The servers that support secure renegotiation indicate so during the SSL handshake phase, and everyone's happy and secure. The issue is with the servers that disable renegotiation, because they provide no indication of their security status. Some are insecure, while some aren't. Without knowing, browsers can't do anything. They can perhaps only inconvenience users and force them to manually configure protection levels.

While it is possible to test for insecure renegotiation (SSL Labs does it), the test is indicative but not conclusive -- there is no way to test for server-initiated renegotiation. Besides, it's not reasonable to expect browsers to test every SSL site they encounter.
[...]
De behaalde hoge score is trouwens ook weer niet helemaal terecht, want als je MSIE zo configureert dat deze jou waarschuwt bij mixed content (zowel http als https content), dan zal ook MSIE je waarschuwen.

Verder klopt het niet dat als je https://secure.security.nl/ opent en inlogt, onmiddellijk na het inloggen naar http://www.security.nl/ wordt doorgestuurd.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.