Tijd voor https ?

[ITnetadmin]

Staat op de planning maar momenteel kunnen we niet upgraden omwille van een bug in de firewall firmware (en ik spreek hier over een van de meest geavanceerde firewall leveranciers ter wereld. Voor de prijs van dat ding koop je meerdere Tesla's ).
In een enterprise omgeving is het alles behalve evident om op de meest recente versies te draaien. Veel userbase gebruikers willen dit maar niet snappen blijkbaar.

Er is uiteraard een verschil tussen "meezijn om mee te zijn" en "meezijn omdat je anders uit de boot valt".
Dat eerste gebeurt nooit in een enterprise, en da's maar goed ook, want de miserie zou niet te overzien zijn.
Maar als dat eerste dat laatste wordt, begin je in je enterprise toch met een probleem te zitten. Zeker als het om een security upgrade draait.

Om effe te overdrijven, "niet meezijn" was geen excuus toen de heartbleed bug in openssl ontdekt werd. Soms worden bepaalde upgrades prioritair overnight.

Maar het is inderdaad altijd een huzarenstukje goochelen om alles een beetje in mekaar te doen passen, en dan worden er prioriteiten gesteld; surfen naar websites is daar dan zelden bij (tenzij het een issue wordt naar de core business toe).

[ Post made via mobile device ]

[ Post made via mobile device ]

[ubremoved_539]

Staat op de planning maar momenteel kunnen we niet upgraden omwille van een bug in de firewall firmware (en ik spreek hier over een van de meest geavanceerde firewall leveranciers ter wereld. Voor de prijs van dat ding koop je meerdere Tesla's ).

Als je firewall niet overweg kan met TLS 1.2 dan zou ik me ernstige bedenkingen maken bij de leverancier... ongeacht hoeveel Tesla's je ervoor kan kopen !

In een enterprise omgeving is het alles behalve evident om op de meest recente versies te draaien. Veel userbase gebruikers willen dit maar niet snappen blijkbaar.

Evident... het is maar hoe je het bekijkt... als je je bedrijf vol stopt met applicaties die zich niet aan standaarden houden en allerlei rariteiten bevatten, tja dan is het niet evident maar dan moet je in eigen boezem kijken !

[meon]

We zijn een jaartje verder en Userbase heeft net een nieuw SSL-certificaatje aangemeten gekregen, dus als je net 10 sec downtime hebt gezien was dat m'n Apache herstart

[CCatalyst]

We zijn een jaartje verder en Userbase heeft net een nieuw SSL-certificaatje aangemeten gekregen, dus als je net 10 sec downtime hebt gezien was dat m'n Apache herstart

Het certificaat is er nu wel, maar laat ons zeggen dat er nog werk aan de winkel is voor de beoogde doelstelling ook bereikt is.

Probleem is vooral de server die uitwisseling van zwakke DH parameters toestaat en zo vulnerable is voor Logjam, en daarnaast ook geen ondersteuning voor Forward Secrecy. Dat zijn wel de prioritaire zaken op dit ogenblik. Daarna kan dan eventueel gezien worden naar de headers die de server meestuurt.

[meon]

Qualys gaf een B score. Ik moet zeggen dat ik die (her)configuratie niet zelf aandurf, I'm more an IIS-guy dan Apache. Maar ik weet 't.

Verstuurd vanaf mijn SM-G930F met Tapatalk

[Tim.Bracquez]

@meon: Gooi er https://www.cloudflare.com/ voor en zet gratis SSL aan. Gelijk caching van alles, die mannen doen het goed!

[Sasuke]

@meon: Gooi er https://www.cloudflare.com/ voor en zet gratis SSL aan. Gelijk caching van alles, die mannen doen het goed!

Seconded ... gebruik dat zelf ook en zie het meer en meer, ook voor high-Traffic websites !

[CCatalyst]

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.

[ubremoved_539]

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.

[tb0ne]

Huidige zijn toch gecrossigned dus eigenlijk geen probleem?

[CCatalyst]

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]

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.

[ubremoved_539]

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.

[CCatalyst]

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.

[ubremoved_539]

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

[road rebel]

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

[freggy]

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?

[ubremoved_539]

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

Hoe doet Let's Encrypt dit dan ?

[xming]

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.

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.

[ubremoved_539]

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.

[meon]

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

[xming]

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.

[ubremoved_539]

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.

[CCatalyst]

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)...

[CCatalyst]

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

[CCatalyst]

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)...

[FlashBlue]

/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...

[driesp]

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.

[johcla]

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.

[blaatpraat]

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...

[Splitter]

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)

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...

[meon]

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 )

[Splitter]

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]

[meon]

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 )

[Splitter]

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

[CCatalyst]

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."

[raf1]

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

[MClaeys]

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

[blaatpraat]

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.

[Splitter]

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"