Waarom geen HTTPS/SSL

[splinterbyte]

Als ik https gebruik krijg ik een username/password auth window met "Userbase Crew only!" als message.
Er kan dus geen enkele non-crew user secure inloggen en secure lezen/antwoorden.

Waarom is dit zo ?

[meon]

Vroeger hadden we zowel http als https open staan voor de site.
Op zich niks mis mee, maar we gebruiken een self-signed certificaat (geen gekocht).
Op zich niks mis mee, maar Google indexeerde zowel de pagina's op http als https. Vervelend, aangezien mensen bij de helft van de resultaten nu een waarschuwing kregen van 'deze beveiligde verbinding is niet veilig' blabla.
Google NIET https laten indexeren is blijkbaar niet vanzelfsprekend. Dus hebben we https://www.userbase.be gewijzigd naar onze interne pagina's met statistieken, webmail, mysql-admin, ... waar een wachtwoord voor nodig is zodat Google deze niet meer indexeert.

Zo goed uitgelegd Sub Zero'ke?

[splinterbyte]

Tja,

wat je evengoed kan doen is de https (of een dubbele ssl config) op een andere poort zetten (bv 4431)
en dan uitleg op de FAQ hier plaatsen...

of is iets als https://ssl.userbase.be...

[gr4vity]

En welk voordeel heeft het voor jou om via SSL te posten of te lezen? Is de communicatie met userbase dan geheim?

[Sub Zero]

Zo goed uitgelegd Sub Zero'ke?

Das heel flink uitgelegd

[_ketter_]

En welk voordeel heeft het voor jou om via SSL te posten of te lezen? Is de communicatie met userbase dan geheim?

hij had het vooral over de inlog-procedure. ssl of client-side encryptie via javascript zou toch wel interessant zijn, denk je niet?

Vroeger hadden we zowel http als https open staan voor de site.
Op zich niks mis mee, maar we gebruiken een self-signed certificaat (geen gekocht).
Op zich niks mis mee, maar Google indexeerde zowel de pagina's op http als https. Vervelend, aangezien mensen bij de helft van de resultaten nu een waarschuwing kregen van 'deze beveiligde verbinding is niet veilig' blabla.
Google NIET https laten indexeren is blijkbaar niet vanzelfsprekend. Dus hebben we https://www.userbase.be gewijzigd naar onze interne pagina's met statistieken, webmail, mysql-admin, ... waar een wachtwoord voor nodig is zodat Google deze niet meer indexeert.

Zo goed uitgelegd Sub Zero'ke?

wat weerhoudt jullie er van via bv. een .htaccess bestandje een rule aan te maken die een verschillende robots.txt kan aansturen naar gelang de toegang via http of https?

[gr4vity]

En welk voordeel heeft het voor jou om via SSL te posten of te lezen? Is de communicatie met userbase dan geheim?

hij had het vooral over de inlog-procedure. ssl of client-side encryptie via javascript zou toch wel interessant zijn, denk je niet?

client-side via javascript is bogus. Zolang de "key" niet via SSL gaat zit je nog steeds met problemen. De oplossing met de robots.txt moeten we even bekijken denk ik.

[splinterbyte]

Welk voordeel ? Secure inloggen vooral natuurlijk.
Nog nooit een probleem gezien als je wilt inloggen op een website zonder https en je zit op een hotspot zonder encryption of netwerk dat je niet vertrouwt ?

[Goendi]

Dat voordeel had je toch ook zelf kunnen bedenken eh gr4vity En ook als ik berichten via UB verstuur, zie ik het ook niet zitten dat iemand mijn tekst kan sniffen...

[Ofloo]

Vroeger hadden we zowel http als https open staan voor de site.
Op zich niks mis mee, maar we gebruiken een self-signed certificaat (geen gekocht).
Op zich niks mis mee, maar Google indexeerde zowel de pagina's op http als https. Vervelend, aangezien mensen bij de helft van de resultaten nu een waarschuwing kregen van 'deze beveiligde verbinding is niet veilig' blabla.
Google NIET https laten indexeren is blijkbaar niet vanzelfsprekend. Dus hebben we https://www.userbase.be gewijzigd naar onze interne pagina's met statistieken, webmail, mysql-admin, ... waar een wachtwoord voor nodig is zodat Google deze niet meer indexeert.

Zo goed uitgelegd Sub Zero'ke?

waarom cacert.org niet gebruiken, .. en mensen het gewoon laten installeren ... en je kan robots.txt verbieden van https te crawlen.