Ga naar inhoud

Het forum is weer online!

Welkom mede-preppers, zoals jullie zien is het forum na 4 jaar weer online. Tijd voor een feestje! Je kunt met je oude gebruikersnaam en wachtwoord inloggen. Als dit is gelukt, pas dan gelijk je e-mailadres aan. Deze klopt namelijk niet meer omdat we die 4 jaar geleden hebben verwijderd.

Weet je je wachtwoord niet meer? Dan kan je de wachtwoord vergeten functie NIET gebruiken, omdat we je e-mailadres dus niet meer hebben. Mail in dat geval naar forum@preppers.nl en noem je gebruikersnaam en voeg een notificatiemail bij van het oude forum als je die nog hebt.

Mocht je echt niks hebben mail ons dan sowieso je gebruikersnaam, we zullen je dan verdere instructies geven!

SSL voor preppers.nl ?


Recommended Posts

Te lui om het allemaal te leze maar mening kan wel ffe. Https maakt het moeilijker on verkeer te onderscheppen zonder dat de gebruiker dit merkt. Wat leuk kan zijn. Het kan eventueel gratis ik ben de ca ffe kwijt (mn werkpc) heeft hem maar t is weekend dus ha mooi niet.

 

Wat betteft tor. Het is heel onhandig om preppers via tor te benaderen. Tenzij iedereen een appart tor account maakt en je nooit de hint laat vallen dat je dezelfe persoon bent.

Link to post
Share on other sites
  • 1 month later...
Begin nu je eigen moestuin. Bekijk de zadenpakketten Op zoek naar waterfilters, messen, tools of lang houdbaar eten? Ga dan naar www.prepshop.nl!

Hoog tijd op weer even op dit punt terug te komen @Enki @martin

 

En wel met mijn voorlopige conclusie dat het niet gaat lukken :( De aanpak die Enki noemde gaat helaas niet op wanneer je enkel registratie en login wilt encrypten, en zoals ik aangaf is dat het enige dat ik zie zitten (om eerder in dit draadje genoemde reden).

 

Antwoord van vbulletin: "There is no option just to have login pages behind SSL. All pages in vBulletin are login pages."

 

Zijn we dan nu helemaal reddeloos en kraakbaar als een natte doos?

Dat schijnt mee te vallen. Zoals ik het begrijp (heb hier niet direct officiele info van vbulletin over kunnen vinden) worden passwords nooit in plain text over de lijn gegooid, maar met client side encryption. Dus "men" kan nooit zomaar je wachtwoord te weten komen. Maar hoe veilig deze methode is kan ik weinig zinnigs over zeggen, wellicht iemand anders wel ...

Link to post
Share on other sites

Wat is dan het probleem om heel preppers.nl over SSL te draaien? Die paar keer dat je een insecure content melding krijgt? Volgens mij kun je dat redelijk makkelijk voorkomen door geen deeplinks meer toe te staan bij het plaatsen van images. Eventueel cache je standaard de embedded images op je eigen server. Voor de video integratie: Vimeo en Youtube draaien standaard al over https.

 

Persoonlijk vind ik het ook onbegrijpelijk als persoonlijke content (en dat is preppers.nl zodra je ingelogd bent) geen gebruik maakt van SSL. Het onderweg aftappen van is zo eenvoudig dat ik - muv preppers.nl - nergens inlog over een http verbinding.

Link to post
Share on other sites
..

Zijn we dan nu helemaal reddeloos en kraakbaar als een natte doos?

Dat schijnt mee te vallen. Zoals ik het begrijp (heb hier niet direct officiele info van vbulletin over kunnen vinden) worden passwords nooit in plain text over de lijn gegooid, maar met client side encryption. Dus "men" kan nooit zomaar je wachtwoord te weten komen. Maar hoe veilig deze methode is kan ik weinig zinnigs over zeggen, wellicht iemand anders wel ...

 

Ik heb even een wireshark capture gemaakt van het inloggedeelte en ik kom (ingekorte versie) op deze info

 

Full request URI: http://preppers.nl/forum/login.php?do=login

HTML Form URL Encoded: application/x-www-form-urlencoded

Form item: "vb_login_username" = "martin"

Form item: "vb_login_password" = ""

Form item: "vb_login_md5password" = "ed3619569a3226f077c0edf06b4a1925"

 

Dus die info blijkt juist te zijn, er gaat geen wachtwoord in ASCII over de lijn, maar in md5 formaat

 

Maar ik sluit me aan bij @f150, waarom niet heel het forum in https.

Ik zie diverse info dat het relatief eenvoudig is om alles om te zetten naar https.

Dat was blijkbaar in de oudere versies een drama, maar dat schijnt tegenwoordig enorm mee te vallen.

Ook de meeste externe bronnen zijn tegenwoordig vrijwel https.

Hoewel ik persoonlijk nogal gemixte gevoelens heb over privacy, zou het wel een goed signaal zijn naar de members om de complete site op https over te schakelen.

Je kan het volgens mij ook keurig mixen en dan auto redirecten. (zodat de google cache niet gelijk gaat flippen)

Link to post
Share on other sites
@f150 @martin Okee okee, ik ga het heroverwegen ... moet het ook eenvoudig mogelijk zijn om http en https parallel te draaien? Dus dat ik er (in eerste instantie, om te testen) https parallel zet, en (nog) niet iedere bezoeker forceer naar https?

 

Ik ben geen vBullitin expert, maar ik kan me niet voorstellen dat dit complex is.

Maar ik vraag me af of het niet slimmer is om gewoon een complete backup te maken van de site, en deze onder beta.preppers.nl te parkeren

en hierna de beta omzetten naar https (als een backup)

Ik denk dat dit een stuk eenvoudiger is qua implementatie, en is de impact op een mogelijke probleem een stuk minder.

Link to post
Share on other sites
Plaats gewoon niks op het forum als je wil dat een ander het niet weet...

Alles wat ik plaats mag voor mijn part door de hele wereld worden gelezen...daarvoor is het een forum...

 

Daar gaat 't echter helemaal niet om.

 

Het gaat er ondere andere om dat 't niemand iets aangaat welke threads jij leest, waar en wat je post en wie je echt bent enzo. Juist op een site als deze is 't belangijk om dat soort privacy te beschermen, al geldt dat eigenlijk gewoon voor elke website.

Link to post
Share on other sites
Euh, waarom niet gewoon 2 apache vhosts, 1 met en 1 zonder SSL en deze gewoon naar dezelfde DocumentRoot wijzen? Ik zie geen reden om lastiger te doen dan dat...

 

Dat is beter dan heb je als bezoeker zelf de keuze of je het forum opent met https:// of http://

Link to post
Share on other sites

http en https voor 'tzelfde domein heeft altijd maar 1 IP adres nodig. Kan ook niet eens met 2 tenzij je op aparte subdomeinen gaat werken. Pas bij meerdere https domeinen kom (kwam) je in de situatie dat je meerdere IP's nodig hebt (had).

 

Met SNI is dat ook niet meer nodig en nu dat windows XP officieel dood is (woohoo!) wordt het gebruik van SNI eindelijk grootschalig mogelijk (XP ondersteunt het niet).

 

Het meerdere IP's verhaal voor https is dus niet meer relevant! :)

Link to post
Share on other sites
http en https voor 'tzelfde domein heeft altijd maar 1 IP adres nodig. Kan ook niet eens met 2 tenzij je op aparte subdomeinen gaat werken. Pas bij meerdere https domeinen kom (kwam) je in de situatie dat je meerdere IP's nodig hebt (had).

 

Met SNI is dat ook niet meer nodig en nu dat windows XP officieel dood is (woohoo!) wordt het gebruik van SNI eindelijk grootschalig mogelijk (XP ondersteunt het niet).

 

Het meerdere IP's verhaal voor https is dus niet meer relevant! :)

 

Moet ik nog nakijken of onze server SNI ondersteunt oid?

Link to post
Share on other sites
Euh, waarom niet gewoon 2 apache vhosts, 1 met en 1 zonder SSL en deze gewoon naar dezelfde DocumentRoot wijzen? Ik zie geen reden om lastiger te doen dan dat...

 

Omdat je dan een 100% gescheiden testomgeving heb.

(uiteraard ook de database dupliceren)

Nu zie ik zelf ook geen enkel gevaar hoe de frontend via https de database om zeep zou kunnen helpen terwijl deze hetzelfde zou moeten functioneren onder http, maar je zal maar tegen een of andere vage php bug aan lopen.

 

En ik ben nogal extreem doorgeslagen als het gaat om een live, en om een testomgeving.

Link to post
Share on other sites
Moet ik nog nakijken of onze server SNI ondersteunt oid?

 

Als ik de header opvraag zie ik dit

 

HTTP/1.1 301 Moved Permanently

Date: Tue, 06 Jan 2015 22:48:39 GMT

Server: Apache/2.2.15 (CentOS)

X-Powered-By: PHP/5.5.20

X-Pingback: http://preppers.nl/xmlrpc.php

Location: http://preppers.nl/

Connection: close

Content-Type: text/html; charset=UTF-8

 

Dus dat mag geen enkel probleem zijn

(minimaal Apache 2.2.12)

Link to post
Share on other sites
  • 1 month later...

Omdat dit draadje gaat over de security van fora, oa de gebruikte Vbulletin software, hieronder een voorbeeld van een PHP exploit dat door Equation Group is gebruikt in de Vbulletin software om discussiefora in het Midden Oosten te hacken. IP zones van Jordanie, Egypte en Turkije zijn uitgesloten:

 

[ATTACH=CONFIG]16695[/ATTACH]

 

Kaspersky is nog op zoek naar white-hat hackers om de volgende hashes te decrypten:

0044c9bfeaac9a51e77b921e3295dcd91ce3956a

06cf1af1d018cf4b0b3e6cfffca3fbb8c4cd362e

3ef06b6fac44a2a3cbf4b8a557495f36c72c4aa6

5b1efb3dbf50e0460bc3d2ea74ed2bebf768f4f7

930d7ed2bdce9b513ebecd3a38041b709f5c2990

e9537a36a035b08121539fd5d5dcda9fb6336423

 

https://securelist.com/files/2015/02/Equation_group_questions_and_answers.pdf

Link to post
Share on other sites

Doe mee aan dit gesprek

Je kunt dit nu plaatsen en later registreren. Indien je reeds een account hebt, log dan nu in om het bericht te plaatsen met je account.

Gast
Reageer op dit topic...

×   Geplakt als verrijkte tekst.   Herstel opmaak

  Er zijn maximaal 75 emoji toegestaan.

×   Je link werd automatisch ingevoegd.   Tonen als normale link

×   Je vorige inhoud werd hersteld.   Leeg de tekstverwerker

×   Je kunt afbeeldingen niet direct plakken. Upload of voeg afbeeldingen vanaf een URL in

×
×
  • Nieuwe aanmaken...