Userbase

Heads up, Userbase gebruikt een TLS certificaat van StartCom.

Mozilla heeft voorgesteld om zowel het Chinese WoSign als StartCom (eigendom van WoSign) uit de lijst van trusted root certificates te smijten, wegens diverse en significante vormen van bedrog en foefelarij met certificaten en met weinig zicht op beterschap.

Het is nog niet zover, maar het lijkt me toch aangeraden om af te stappen van WoSign/StartCom. Let's Encrypt is bijvoorbeeld een mooi gratis alternatief, dat op een Westerse manier beheerd wordt, met veel transparantie en zonder het bedrog en de geheimdoenerij van WoSign.

The Let’s Encrypt root key (ISRG Root X1) will be trusted by default in Firefox 50, which is scheduled to ship in Q4 2016.

Blijkbaar ben je voorlopig nog beter af met StartCom dan Let's Encrypt als het over Mozilla gaat.

Huidige zijn toch gecrossigned dus eigenlijk geen probleem?

r2504 schreef:
The Let’s Encrypt root key (ISRG Root X1) will be trusted by default in Firefox 50, which is scheduled to ship in Q4 2016.
Blijkbaar ben je voorlopig nog beter af met StartCom dan Let's Encrypt als het over Mozilla gaat.

Zoals tb0ne hierboven al aanhaalt, huidige certs van Let's Encrypt zijn cross-signed door IdenTrust met een root die wel al in FireFox zit.

Zou anders wel straf zijn, Mozilla is immers een hoofdsponsor van Let's Encrypt.

Dat er tijd over gaat alvorens browsers een nieuwe root willen aanvaarden is normaal (WoSign historie illustreert waarom), en Mozilla doet er goed aan om "hun" Let's Encrypt ook niet voor te trekken op anderen op dat vlak.

CCatalyst schreef:Heads up, Userbase gebruikt een TLS certificaat van StartCom.

...

En het is van dat. WoSign en StartCom vliegen uit Mozilla. https://blog.mozilla.org/security/2016/ ... tificates/

Enkel nieuwe certs worden niet meer vertrouwd, dus met de huidige cert hier ben je nog goed tot de vervaldatum, 22 september 2019

Tenzij dat WoSign een andere vervaldatum hanteert en het certificaat eerder intrekt.

CCatalyst schreef:En het is van dat. WoSign en StartCom vliegen uit Mozilla. https://blog.mozilla.org/security/2016/ ... tificates/

Ik heb gisteren een nieuwe certificaat aangemaakt bij StartSSL en kreeg de volgende melding;

Welcome!
Mozilla decided to distrust all StartCom root certificates as of 21st of October, this situation will have an impact in the upcoming release of Firefox in January. StartCom will provide an interim solution soon and will replace all the issued certificates from that date in case of requested. Meanwhile StartCom is updating all their systems and will generate new root CAs as requested by Mozilla.

r2504 schreef:
Ik heb gisteren een nieuwe certificaat aangemaakt bij StartSSL en kreeg de volgende melding;

Welcome!
Mozilla decided to distrust all StartCom root certificates as of 21st of October, this situation will have an impact in the upcoming release of Firefox in January. StartCom will provide an interim solution soon and will replace all the issued certificates from that date in case of requested. Meanwhile StartCom is updating all their systems and will generate new root CAs as requested by Mozilla.

Jep, de Chinezen en hun beloftes vertrouwen, WCGW?

Smijt dat certificaat maar weg en neem een Let's Encrypt cert in de plaats. Lees de hele achtergrond nog eens voor het waarom. WoSign zijn foefelaars.

CCatalyst schreef:Smijt dat certificaat maar weg en neem een Let's Encrypt cert in de plaats.

Moest Let's Encrypt toelaten dat je gewoon een CSR opgaf en je meteen je certificaat kreeg... nee, zo'n bizarre ACME tool

Op een eigen kleinschalig website met vragenlijsten (limesurvey) ben ik ook nog met http. Wat moet ik doen om over te schakelen op https?

r2504 schreef:Moest Let's Encrypt toelaten dat je gewoon een CSR opgaf en je meteen je certificaat kreeg... nee, zo'n bizarre ACME tool

En hoe moet Let's Enrypt dan dan automatisch/zonder grote kosten verifiëren dat jij werkelijk de beheerder bent van het domein waarvoor je een certificaat aanvraagt?

Zoals StartSSL dit doet... een verificatie mail sturen naar [email protected]

Hoe doet Let's Encrypt dit dan ?

road rebel schreef:Op een eigen kleinschalig website met vragenlijsten (limesurvey) ben ik ook nog met http. Wat moet ik doen om over te schakelen op https?

cloudflare of let's encrypt.

r2504 schreef:Hoe doet Let's Encrypt dit dan ?

Of via een DNS record, er bestaan scriptjes om dit allemaal automatisch te late verlopen zonder gebruik van de officiële acme tool.

xming schreef:Of via een DNS record, er bestaan scriptjes om dit allemaal automatisch te late verlopen zonder gebruik van de officiële acme tool.

En hoe doe ik dat op m'n Routerbord ? Scriptjes zijn leuk maar liever eerst de basis en dat is nog steeds een CSR en CER.

StartSSL heeft ondertussen ook API's... doodsimpel en gewoon HTTP POST/GETs... CSR POST'en, certificaat terug ophalen ipv. gans dat ACME gedoe.

En Let's Encrypt's concept is onbruikbaar in een Windows webfarm waarbij IIS zelf z'n certificaten managed (Centralized Certificates)

r2504 schreef:
xming schreef:Of via een DNS record, er bestaan scriptjes om dit allemaal automatisch te late verlopen zonder gebruik van de officiële acme tool.
En hoe doe ik dat op m'n Routerbord ? Scriptjes zijn leuk maar liever eerst de basis en dat is nog steeds een CSR en CER.

StartSSL heeft ondertussen ook API's... doodsimpel en gewoon HTTP POST/GETs... CSR POST'en, certificaat terug ophalen ipv. gans dat ACME gedoe.

het is gewoon csr, die tools maken het "gemakkelijker". Als je weet hoe je keys/crs aanmaakt, DNS/web files aanpast, POSTen en dan de certs op de juiste plaatsen zet, dan heb je die acme tool echt niet nodig.

meon schreef:En Let's Encrypt's concept is onbruikbaar in een Windows webfarm waarbij IIS zelf z'n certificaten managed (Centralized Certificates)

Dat kan je Let's Encrypt natuurlijk moeilijk kwalijk nemen.

En tenslotte sluit nu ook Google nog aan:

https://security.googleblog.com/2016/10 ... rtcom.html

Apple (Safari en co) was trouwens de eerste, heeft in september WoSign er al uitgesmeten.

Het lijstje van de grote browsers die WoSign/StartCom niet langer vertrouwen is bij deze compleet.

Bij deze mag je dan ook concluderen: RIP WoSign/StartCom/StartSSL (1999-2016)...

Symantec zou ik ook mijden voor een poosje. Ook daar rommelt het.

Ondertussen is Chrome 59 verschenen. Het Startcom root cert is geschrapt. Deze site gebruikt echter nog steeds dat Startcom cert.

Ik kan dan ook niet meer met https://userbase.be verbinden. NET::ERR_CERT_REVOKED

Het is nu echt wel 5 na 12 om een letsencrypt oid te installeren... Eerste melding hieromtrent dateert al van 27 september (zie hierboven)...

/me knipoogt naar Meon

Had dat met de dev versie al een tijd voor, dus ze weten het

Maar feit is dat letsencrypt echt niet gebruiksvriendelijk is eigenlijk...

Voor een tientje per jaar heb je een betalend certificaat.
Je kan zelfs meteen voor meerdere jaren registreren als je geen zin hebt om elk jaar opnieuw een nieuwe private key te genereren.

Eerlijk, de tijd dat je stopt om let's encrypt te configureren op de server tov de kost van het goedkoopste certificaat weegt mij niet op.
Of het moet zijn dat het om meerdere domeinen gaat dat je wil gaan beveiligen.

Omdat mijn NAS problemen had met het vernieuwen van Let's Encrypt, heb ik nu een paar Comodo PositiveSSL certificaten gekocht via gogetssl.
Kostprijs: 11 euro voor 3 jaar.

driesp schreef:Voor een tientje per jaar heb je een betalend certificaat.
Je kan zelfs meteen voor meerdere jaren registreren als je geen zin hebt om elk jaar opnieuw een nieuwe private key te genereren.

Eerlijk, de tijd dat je stopt om let's encrypt te configureren op de server tov de kost van het goedkoopste certificaat weegt mij niet op.
Of het moet zijn dat het om meerdere domeinen gaat dat je wil gaan beveiligen.

From scratch:
2 commando's intikken op CLI, en 1 crontab toevoegen (renewbot autorenew of iets dergelijks).
Kost mij effectief minder tijd dan een TLS cert te kopen.

Nieuw domein toevoegen: 1 commando intikken op CLI.
Nog minder werk dus.

En gezien het feit dat een korte renew periode veiliger blijkt te zijn dan een lange, maakt LE wel de voorkeur, tenzij je een specialeke wenst (wildcard, of EV, of ...).

Maar goed: Chrome is up-to-date hier (v59) en UB laadt nog perfect in over HTTPS.
Enkel nog steeds de melding ivm mixed content...

FlashBlue schreef:Maar feit is dat letsencrypt echt niet gebruiksvriendelijk is eigenlijk...

serieus? ik gebruik dat al jaren, zie écht niet het ongebruiksvriendelijke in?

ff cert-bot (of tegenwoordig beter: binaries rechtstreeks uit je distro sources) laten lopen met een paar params, een crontabje en klaar.

met de binary is het gewoon dit en bent al vertrokken:
/usr/bin/letsencrypt certonly --webroot --webroot-path /var/www/vhost -d userbase.be -d http://www.userbase.be --email [email protected]
(tuurlijk wel ff de vhost aanpassen naar /etc/letsencrypt/live/userbase.be/.... voor key en chain)

driesp schreef:Eerlijk, de tijd dat je stopt om let's encrypt te configureren op de server tov de kost van het goedkoopste certificaat weegt mij niet op.

again, seriously? op 5 minuten tijd heb je jaarlijks 10 euro winst...

Help mij dan eens, ik was een nieuwe CSR aan't opstellen, maar gekke errors

.

Code: Selecteer alles

meon@prod:/home/meon$ sudo openssl req -new -sha256 -key ./userbase.be.key -subj "/" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=[SAN]\nsubjectAltName=DNS:userbase.be,DNS:www.userbase.be")) -out ./req.csr

Code: Selecteer alles

error on line -1 of /dev/fd/63
140505886852776:error:02001002:system library:fopen:No such file or directory:bss_file.c:169:fopen('/dev/fd/63','rb')
140505886852776:error:2006D080:BIO routines:BIO_new_file:no such file:bss_file.c:172:
140505886852776:error:0E078072:configuration file routines:DEF_LOAD:no such file:conf_def.c:197:

(Bovenstaande is in Windows nog een beetje complexer, maar daar lukt het me tenminste wél

)

je hoeft niet perse een eigen csr te maken voor letsencrypt, dat is allemaal volledig geautomatiseerd

(je KAN het wel - maar tenzij je TLSA records gebruikt heeft het éigenlijk niet echt veel belang)

also: verouderde openssl dat je die error krijgt? dacht toch dat dat ooit zo was.
ik heb atm deze 2 openssl versies en 0 issues:

openssl/trusty-updates,trusty-security,now 1.0.1f-1ubuntu2.22 amd64 [installed]
openssl/xenial-updates,now 1.0.2g-1ubuntu4.8 amd64 [installed,automatic]

Ik heb 't nu niet per sé over Let's encrypt, en al helemaal niet over hun client

.

Als ik de oneliner goed decodeer injecteer je je openssl-config in de -config parameter en vervang je in die string het gedeelde voor de subjectalternatename? Is het dat deel dat fout gaat? (Ik ben bash-notatie niet gewoon, geef mij maar PowerShell

)

met je commando's is niets mis

en idd, je steekt de config in de commandline, en ik geloof idd dat die de string dan zo vervangt... maar replacement/regex related stuff is niet mijn forté

iig:

Code: Selecteer alles

 H gallifrey.peeters.io  bpeeters  ~ | tmp  openssl genrsa -out test.key 2048
Generating RSA private key, 2048 bit long modulus
....................+++
........................................+++
e is 65537 (0x10001)
 H gallifrey.peeters.io  bpeeters  ~ | tmp  openssl req -new -sha256 -key ./test.key -subj "/" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=[SAN]\nsubjectAltName=DNS:userbase.be,DNS:www.userbase.be")) -out ./req.csr
 H gallifrey.peeters.io  bpeeters  ~ | tmp  ls -lash
total 16K
4.0K drwxr-xr-x  2 bpeeters bpeeters 4.0K Jul  5 23:14 .
4.0K drwxr-xr-x 12 bpeeters bpeeters 4.0K Jul  5 23:14 ..
4.0K -rw-r--r--  1 bpeeters bpeeters  944 Jul  5 23:14 req.csr
4.0K -rw-r--r--  1 bpeeters bpeeters 1.7K Jul  5 23:14 test.key
 H gallifrey.peeters.io  bpeeters  ~ | tmp  cat req.csr 
-----BEGIN CERTIFICATE REQUEST-----
MIICfzCCAWcCAQAwADCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJNr
DSn/FqVG+hKc/kuO19YbIBpOsRONgLrstRvEKBVBUaqXaCfz8R9Rkm5bUO9pKaq2
Vy7bq+vCshdGOoTyddQXtrWJv8OaMZp95u16br+h6hTYYL1ZpeAfmJho2aCl+vhw
adxEBuqsYNmY3wVYCU7apvUJro6FFR+X4IK+gulZPXvK+VNFUeOeUEImbFEt+eBq
6pjRAoatjLpUzIdhgi+HQlaSnmqLSGUEZamAYz2Y7doo7TCQwpjHfOioH0oFwPMG
GmhF7iLt67t/WshHsHUnAAZH9riB1DChPhuXURnHVLEjMhG+DivbRCz+EtkbY25x
aaDg9gb4QI6AAcvu730CAwEAAaA6MDgGCSqGSIb3DQEJDjErMCkwJwYDVR0RBCAw
HoILdXNlcmJhc2UuYmWCD3d3dy51c2VyYmFzZS5iZTANBgkqhkiG9w0BAQsFAAOC
AQEAK5LqmhJdEkoXsB09k5dEb982TSi7Zl8G1CUehvGVe9f/9ByX/Pl7JyFI8GZo
gA3FLdlr0RrNpmavuDpThjVi/DlCZQXcmQXt8Yjina8Nih5ZZSWM/wm8l7KzBNXE
yhCrHnxE59nHRt2/mixvH4HTmyznTrtiCmyE0/hoZXnxqCjIJEORa87L1aAiTtm0
28FKHTHvPhsX+95H5imRQYEZD64jNjRvbBh6R4U2sR0AIoPcuEZt5EluPNwFQ1ny
gFSEUXugLXQgWgDnjad4fH4XW832euV7jSSGQQRu3vBkdE0mm8msjHlc//+looPO
GJNmGkaRbXYCDNI8r/55VW/T7g==
-----END CERTIFICATE REQUEST-----

ik zou dus toch een keertje zoals in mijn edit hierboven gezegd eens kijken naar je versie van openssl

blaatpraat schreef: Maar goed: Chrome is up-to-date hier (v59) en UB laadt nog perfect in over HTTPS.
Enkel nog steeds de melding ivm mixed content...

Inderdaad, my bad, reden dat het bij mij niet meer werkt is niet Chrome 59 maar wel macOS High Sierra (10.13). Apple zegt vanaf die versie van macOS het vertrouwen op in Startcom/WoSign in de keychain. Chrome gebruikt op macOS de keychain van Apple. Ook op Safari werkt het (uiteraard) niet meer, op Firefox wel nog gezien die een eigen implementatie gebruikt ipv de Apple keychain.

Voor andere besturingsystemen, wat Chrome betreft is het vanaf Chrome 61 (september 2017) definitief gedaan. Userbase staat momenteel nog op de whitelist, vanaf versie 61 wordt die whitelist geschrapt.

Laat dit geen reden zijn voor nog meer uitstel, want zoals die post zelf zegt: "Sites still using StartCom or WoSign-issued certificates should consider replacing these certificates as a matter of urgency to minimize disruption for Chrome users."

blaatpraat schreef:Enkel nog steeds de melding ivm mixed content...

Dat komt omdat de avatar van Sasuke en anderen met een externe avatar zoals MClaeys via http worden ingeladen.
Er moeten dus twee dingen aangepast worden:
- bestaande avatar url's naar https aanpassen
- nieuwe avatar url's verplichten https te gebruiken

Ik zal de mijne deze week eens naar https wijzigen, is nu doorgelinkt naar een externe site, vandaar.

Sent from my Lenovo K33a48 using Tapatalk

raf1 schreef:
blaatpraat schreef:Enkel nog steeds de melding ivm mixed content...
Dat komt omdat de avatar van Sasuke en anderen met een externe avatar zoals MClaeys via http worden ingeladen.
Er moeten dus twee dingen aangepast worden:
- bestaande avatar url's naar https aanpassen
- nieuwe avatar url's verplichten https te gebruiken

Niet akkoord.
Er bestaan genoeg oplossingen die je als forumeigenaar kan toepassen, waarbij je je leden niet hoeft lastig te vallen.
Als je je leden verplicht om een HTTPS avatar te gebruiken, vallen er veel externe webhosts uit de boot, aangezien die geen HTTPS aanbieden. Dit mag niet het probleem van UB vormen, noch het probleem van de leden hier. Dit mag enkel het probleem van die specifieke webhost vormen, de dag dat HTTP als onveilig aanzien wordt door de browsers.

blaatpraat schreef:Er bestaan genoeg oplossingen die je als forumeigenaar kan toepassen, waarbij je je leden niet hoeft lastig te vallen.
Als je je leden verplicht om een HTTPS avatar te gebruiken, vallen er veel externe webhosts uit de boot, aangezien die geen HTTPS aanbieden. Dit mag niet het probleem van UB vormen, noch het probleem van de leden hier. Dit mag enkel het probleem van die specifieke webhost vormen, de dag dat HTTP als onveilig aanzien wordt door de browsers.

wut?

1) http is altijd al onveilig geweest (het ligt maar net aan wat je veilig noemt... log jij op de bank in op http?)

2) ben benieuwd welke oplossingen jij kan aanhalen dat je op een forum kan toepassen zonder dat de leden "lastiggevallen" moeten worden of hun avatar kwijt zijn, en toch https zonder waarschuwing kan krijgen? afaik... zijn er geen. mixed content is mixed content.

3) "vallen er veel externe webhosts uit de boot" again wut? noem er mij 3 die populair zijn en geen https ondersteunen... en geef me vervolgens een reden waarom ze het niet zouden in orde brengen, het kost letterlijk niets meer.

@beheer: gewoon een sql statement doen van replace http door https... en de avatars die breken, "tant pis"

Splitter schreef:
blaatpraat schreef:Er bestaan genoeg oplossingen die je als forumeigenaar kan toepassen, waarbij je je leden niet hoeft lastig te vallen.
Als je je leden verplicht om een HTTPS avatar te gebruiken, vallen er veel externe webhosts uit de boot, aangezien die geen HTTPS aanbieden. Dit mag niet het probleem van UB vormen, noch het probleem van de leden hier. Dit mag enkel het probleem van die specifieke webhost vormen, de dag dat HTTP als onveilig aanzien wordt door de browsers.
wut?

1) http is altijd al onveilig geweest (het ligt maar net aan wat je veilig noemt... log jij op de bank in op http?)

Aangezien ik weet wat het verschil is tussen HTTP en HTTPS, weet ik dat ja.
Maar voorlopig wordt een certificaat die 1 minuut vervallen is, nog steeds als onveilig aangeduid, waar een webhosting zonder TLS als neutraal aangeduid door webbrowsers.
Jan met de pet zal dus een HTTP site als veiliger aanzien dan een HTTPS site met een certificaat die 1 minuut vervallen is, en even veilig als met een geldig certificaat.
Dit zal binnenkort veranderen, als de browsermakers eindelijk HTTP als onveilig zullen aanduiden.

2) ben benieuwd welke oplossingen jij kan aanhalen dat je op een forum kan toepassen zonder dat de leden "lastiggevallen" moeten worden of hun avatar kwijt zijn, en toch https zonder waarschuwing kan krijgen? afaik... zijn er geen. mixed content is mixed content.

Atmos Camo, zelf in gebruik, net als veel grote sites waar men leden heeft die avatars en/of onderschriften gebruikten.

3) "vallen er veel externe webhosts uit de boot" again wut? noem er mij 3 die populair zijn en geen https ondersteunen... en geef me vervolgens een reden waarom ze het niet zouden in orde brengen, het kost letterlijk niets meer.

Uit mijn hoofd: geen idee.
Een half jaar geleden waren er alvast nog veel leden op mijn forum die een externe avatar hadden over HTTP.
Als ik manueel dit omvormde naar HTTPS, werkte dit niet.
Met camo is dit opgelost: alles loopt over HTTPS, behalve de image ophaling door mijn server (en niet door de bezoeker). Mijn eigen content is volledig over HTTPS, en je krijgt geen mixed content als eindgebruiker.
En geen last van forumleden waarbij hun avatar plots niet meer werkt.

@beheer: gewoon een sql statement doen van replace http door https... en de avatars die breken, "tant pis"

Mooi staaltje klantvriendelijkheid.

Splitter schreef:2) ben benieuwd welke oplossingen jij kan aanhalen dat je op een forum kan toepassen zonder dat de leden "lastiggevallen" moeten worden of hun avatar kwijt zijn, en toch https zonder waarschuwing kan krijgen? afaik... zijn er geen. mixed content is mixed content.

Bij tweakers.net zijn ze onlangs overgeschakeld op HTTPS-only. De problematiek van mixed content (zeer courant op hun forum) hebben ze aangepakt door een eigen HTTPS(-reversed)-proxy (niet zeker) te gebruiken om alle mixed content 'achter te verbergen'.

@James.: ook zij maken gebruik van Atmos Camo, dacht ik.

Dan even een ander bericht:
Ik heb zonet mijn Chrome geüpdatet naar 60 (59 is buggy onder Windows 10, hopelijk werkt deze beter).
Vanaf nu krijg ik inderdaad de melding dat UB niet veilig is om te bezoeken.

blaatpraat schreef:Atmos Camo, zelf in gebruik, net als veel grote sites waar men leden heeft die avatars en/of onderschriften gebruikten.

ok, kende ik niet... al lijkt het me een beetje oplapwerk om de echte issues te negeren (de internet versie van klimaatopwarming?)

blaatpraat schreef:
splitter schreef: @beheer: gewoon een sql statement doen van replace http door https... en de avatars die breken, "tant pis"
Mooi staaltje klantvriendelijkheid.

het is nu niet dat ze op een technisch forum niet in staat zijn hun avatar even aan te passen, he?
en again, ik denk dat er érg weinig avatars geladen worden van plaatsen waar https niet mogelijk is.

Splitter schreef:
blaatpraat schreef:Atmos Camo, zelf in gebruik, net als veel grote sites waar men leden heeft die avatars en/of onderschriften gebruikten.
ok, kende ik niet... al lijkt het me een beetje oplapwerk om de echte issues te negeren (de internet versie van klimaatopwarming?)

Je zou dit inderdaad zo kunnen zien.
Ik zie het eerder als een manier waarmee je je eigen problemen oplost, zodat jij perfect in orde bent en niet meer afhankelijk van derde partijen die niet in orde zijn.
Gezien het feit dat TLS meer en meer afgedwongen zal worden, zullen die derde partijen wel snel overschakelen, hoop ik, al vrees ik voor een nieuw IE6 debacle (gewoon op hun website plaatsen dat ze geen nieuwere browsers ondersteunen). Met zo'n proxies kunnen deftige webbeheerders dit toch al tackelen voor zichzelf.

Wat als iemand

Code: Selecteer alles

[img][/img]

gebruikt, met een HTTP afbeelding? Tenzij custom code voor je BB-parsing kun je dit niet tegenhouden, of je moet iedere nacht een SQL query draaien die het allemaal wijzigt.

blaatpraat schreef:Er bestaan genoeg oplossingen die je als forumeigenaar kan toepassen, waarbij je je leden niet hoeft lastig te vallen.

Ik vind het juist wel nuttig om forumgebruikers lastig te vallen en bewust te maken van https-gebruik en veiligheid op internet in het algemeen. Op die manier zullen de externe hosts ook verplicht worden om https te gebruiken en dat kan je alleen maar toejuichen.

Een privébericht met de aankondiging van deze wijziging is misschien wel aangewezen zodat iedereen op voorhand z'n avatar kan aanpassen.

blaatpraat schreef: Gezien het feit dat TLS meer en meer afgedwongen zal worden, zullen die derde partijen wel snel overschakelen, hoop ik, al vrees ik voor een nieuw IE6 debacle (gewoon op hun website plaatsen dat ze geen nieuwere browsers ondersteunen).

zoals proximus met hun proximustv... "oh, firefox schakelt npapi support uit dus silverlight werkt niet meer? oh well, "vereisten: internet explorer 11"... done

blaatpraat schreef: Wat als iemand
Code: Selecteer alles
[img][/img]
gebruikt, met een HTTP afbeelding? Tenzij custom code voor je BB-parsing kun je dit niet tegenhouden, of je moet iedere nacht een SQL query draaien die het allemaal wijzigt.

hmm, tgoh.. ik denk als je de code maakt dat die // doet ipv http of https te kiezen dat dat wel zal meevallen? dan gaat die voor https enabled zowiezo https kiezen als userbase over https geladen is.
maar idd, je krijgt dan wel weer mixed content of gebroken afbeeldingen.

nobody said it would be easy, maar het "we moeten zoveel mogelijk https gebruiken" verhaal gaat toch vlotter als het ipv6 verhaal.

EDIT:

kijk meon, zo moet het: https://observatory.mozilla.org/analyze ... peeters.io

(maar das maar een utopie, ik zou voor userbase *NOOIT* CSP toepassen, f*ing pain in the ass)

Userbase

Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?

Re: Tijd voor https ?