[SSL] Let's Encrypt. Wachten of alternatief zoeken

[JeroenED]

Hey,

Ooit had ik op tweakers gelezen over let's encrypt (nieuws: EFF wil gratis certificaten uitdelen via onafhankelijke certificaatautoriteit)

Doordat ik mijn eigen hosting doe (op dit moment zonder SSL) en wel geïnteresseert ben in SSL vroeg ik mij af of dit wel het wachten waard is.

Mijn voornaamste vrees is dat de certificaten snel ongeldig zullen worden verklaard. Met een beetje technische kennis (Linux is niet zo moeilijk) kan je op 1,2,3 een certificaat genereren voor een domein waarlangs je dan met gemak tonnen spam mee kan versturen.

Mijn vraag:
Is let's encrypt het wachten waard (vermoedelijk augustus, site wijzigd veel) of zou ik toch beter SSL aan mij laten voorbij gaan (of via andere authoriteit gaan)

FYI: https://letsencrypt.org/

Met vriendelijke groet

Jeroen

[Juup]

Bij startssl kun je gratis een SSL cert (DV) aanvragen:
https://www.startssl.com/

[ Voor 6% gewijzigd door Juup op 02-04-2015 22:56 ]

[Centurius]

Zeker als je in hosting zit komt het voor je klanten toch wel een stuk veiliger over dat je je certificaten gewoon bij een betaalde professionele instantie haalt die een iets uitgebreidere controle uitvoeren.

[JeroenED]

@Centurius Ik zit niet echt in hosting. Ik host gewoon mijn eigen website zelf (via VPS bij OVH) Ik zal hooguit websites hosten voor vrienden en mensen die ik ken.

@Jaaap Hartelijk dank voor de link.

[MrChillax]

Wat voor websites host je? Blogs, webshops, portfolios?
Als je graag SSL wilt gebruiken zou ik gewoon eentje kopen als ik jou was. Zijn niet duur, je kunt al een rapidssl kopen voor € 10,09 p.j of een positivessl voor € 8,30 p.j

[Verwijderd]

Ik heb vanavond Let's Encrypt certificaten in gebruik genomen. So far so good...

Die autoconfiguratie tool van ze werkt vooralsnog niet (op mijn server), maar handmatig certificaten ophalen en die in je virtualhosts of wat je ook gebruikt stoppen werkt prima.

code:

./letsencrypt-auto certonly --standalone -d example.com -d www.example.com

https://letsencrypt.org/howitworks/

Ik heb een Ubuntu 14.04 server en draai Apache2.

In actie:
https://kevindebie.nl/

Enige "meh" tot dusver is dat certificaten elke 90 dagen ververst moeten worden. Maargoed dat valt verder prima in je update/onderhoud schema te verwerken. Of een cron...

[ Voor 14% gewijzigd door Verwijderd op 04-01-2016 00:10 ]

[MrChillax]

Heb ook gister een SSL cert. aangemaakt bij Let's Encrypt. Ziet er goed uit geen enkel probleem mee gehad.

De autoconfiguratie werkt bij mij wel (Debian 8 "Jessie"), en geeft je een mooi simpel configuratie menu


De site is volledig gecodeerd:

Had echter nog niet gezien dat het inderdaad maar 90 dagen geldig is. Zal dus een cron moeten maken voor de renewal om het snel en automatisch te doen.
https://letsencrypt.readt...latest/using.html#renewal

[SL3Y4R]

Verwijderd schreef op zondag 03 januari 2016 @ 23:50:
Ik heb vanavond Let's Encrypt certificaten in gebruik genomen. So far so good...

Die autoconfiguratie tool van ze werkt vooralsnog niet (op mijn server), maar handmatig certificaten ophalen en die in je virtualhosts of wat je ook gebruikt stoppen werkt prima.

code:

./letsencrypt-auto certonly --standalone -d example.com -d www.example.com

https://letsencrypt.org/howitworks/

Ik heb een Ubuntu 14.04 server en draai Apache2.

In actie:
https://kevindebie.nl/

Enige "meh" tot dusver is dat certificaten elke 90 dagen ververst moeten worden. Maargoed dat valt verder prima in je update/onderhoud schema te verwerken. Of een cron...

Ik heb je site bekeken via google chrome op android, en die geeft een melding dat er wat mis is..

[Verwijderd]

SL3Y4R schreef op maandag 04 januari 2016 @ 16:42:
[...]


Ik heb je site bekeken via google chrome op android, en die geeft een melding dat er wat mis is..

Android is volgens mij nog niet bekend met Let's Encrypt als CA...
Op mijn telefoon heb ik ook nog cert meldingen.

Alle normale (actuele) browsers werken m.i. prima.

[CyBeR]

Nog geen enkele browser kent Let's Encrypt als CA. Op dit moment werken die certificaten door middel van cross signing. Praktisch gezien is Let's Encrypt op dit moment alleen nog een subordinate CA.

De signende CA daarvan echter is wel al een flinke tijd bekend dus als je nu waarschuwingen krijgt, heb je wellicht de CA chain op je server niet goed ingesteld.

De melding van Chrome aangaande https://kevindebie.nl/ betreft overigens mixed content: je site laadt scripts in die niet van https-sites komen.

[ Voor 16% gewijzigd door CyBeR op 04-01-2016 17:39 ]

[azerty]

Verwijderd schreef op zondag 03 januari 2016 @ 23:50:
...

Enige "meh" tot dusver is dat certificaten elke 90 dagen ververst moeten worden. Maargoed dat valt verder prima in je update/onderhoud schema te verwerken. Of een cron...

Ik heb een klein scriptje gemaakt dat elke week door de cron aangeroepen wordt (ook al omdat ik het manueel zou moeten doen omdat de nginx plugin nog niet helemaal goed werkt):

code:

#!/bin/bash
#
# This script will renew all the domains listed in the array
domains=(domein.be domein.nl)

echo "Starting renewal process for domains"

# Generate a new certificate for each domain
for domain in ${domains[@]}; do
        echo "Renewing domain ${domain}"
        /usr/src/letsencrypt/letsencrypt-auto certonly -a webroot --user-agent "" --rsa-key-size 4096 --renew-by-default --webroot-path /tmp -d ${domain}
done

echo "Reloading Nginx"
# Reload nginx
/usr/sbin/service nginx reload

echo "Certificates regenerated"

Verder heeft bij mij iedere nginx-config de volgende sectie:

code:

location /.well-known/acme-challenge {
                root /tmp;
        }

Werkt goed tot nu toe

Edit: gaat elke week draaien, want uiteraard is het dankzij de automatiseren geen enkel probleem om dat te doen

[ Voor 5% gewijzigd door azerty op 04-01-2016 17:53 ]

[Verwijderd]

CyBeR schreef op maandag 04 januari 2016 @ 17:38:
Nog geen enkele browser kent Let's Encrypt als CA. Op dit moment werken die certificaten door middel van cross signing. Praktisch gezien is Let's Encrypt op dit moment alleen nog een subordinate CA.

De signende CA daarvan echter is wel al een flinke tijd bekend dus als je nu waarschuwingen krijgt, heb je wellicht de CA chain op je server niet goed ingesteld.

De melding van Chrome aangaande https://kevindebie.nl/ betreft overigens mixed content: je site laadt scripts in die niet van https-sites komen.

Ik had de fullchain file gebruikt ipv de cert en chain los maar blijkbaar werkt dat niet altijd inderdaad, na dat aangepast te hebben werkt het wel... ook op droid.
Mixed content kan kloppen, wordt niet persé rekening gehouden met https, het is maar een filler/placeholder pagina immers.

[ Voor 9% gewijzigd door Verwijderd op 04-01-2016 17:52 ]

[8088]

Verwijderd schreef op maandag 04 januari 2016 @ 17:50:
Mixed content kan kloppen, wordt niet persé rekening gehouden met https, het is maar een filler/placeholder pagina immers.

Wat is dan het nut van een SSL-certificaat? Je implementatie is sowieso wel vatbaar voor verbetering.

[Verwijderd]

8088 schreef op maandag 04 januari 2016 @ 18:01:
[...]

Wat is dan het nut van een SSL-certificaat? Je implementatie is sowieso wel vatbaar voor verbetering.

Dat is er voor die specifieke pagina niet.
Er zit meer achter, zoals privé webmail interface waar ik wel eens op ingelog.
Primair natuurlijk gewoon kennisvergaring.

Uit je link kan ik geen probleem destileren trouwens, die wil niet echt laden.
Wat is er volgens jou concreet mis?

[begintmeta]

Ik zie weinig reden over te stappen van startssl moet ik zeggen, maar let's encrypt is op zich wel een aardig initiatief laagdrempeliger ssl beschikbaar te maken.

Verwijderd schreef op maandag 04 januari 2016 @ 18:05:
...
Uit je link kan ik geen probleem destileren trouwens, die wil niet echt laden.
Wat is er volgens jou concreet mis?

Er zijn desgewenst wel wat verbeterpuntjes, zoals op zich ook wel staat aangegeven:

This server accepts RC4 cipher, but only with older protocol versions. Grade capped to B.
The server does not support Forward Secrecy with the reference browser.
This server's certificate chain is incomplete. Grade capped to B.

Op zich geen grote moeite dat te verbeteren, zou je dat willen.

[8088]

Verwijderd schreef op maandag 04 januari 2016 @ 18:05:
Uit je link kan ik geen probleem destileren trouwens, die wil niet echt laden.
Wat is er volgens jou concreet mis?

Er staat o.a. het volgende:

This server accepts RC4 cipher, but only with older protocol versions. Grade capped to B. MORE INFO »»
The server does not support Forward Secrecy with the reference browsers. MORE INFO »
This server's certificate chain is incomplete. Grade capped to B.
This site works only in browsers with SNI support.

Alleen SNI support vereisen lijkt me geen issue. Voor een volledige scan kun je hier terecht: https://www.ssllabs.com/ssltest/index.html

[Verwijderd]

Certificate chain issue heb ik zonet reeds hersteld. Dat gedoe over RC4 zal ik vanavond eens nader bekijken, thanks!

Edit:

Das wel een issue ja.
Fixed, krijgt nu een A-, vind het wel weer even oké.
Dank voor de heads up allen.

[ Voor 34% gewijzigd door Verwijderd op 04-01-2016 18:40 ]

[CyBeR]

SNI-only levert je inderdaad geen minpunten op.

Voor A+ moet je HSTS headers meesturen, anders krijg je maximaal A.

Voor de volledigheid een HAProxy config waarmee je A+-resultaat krijgt:

global
        log /dev/log local0
        log /dev/log   local1 notice
        #log loghost    local0 info
        maxconn 4096
        chroot /var/lib/haproxy
        uid 99
        gid 99
        daemon
        #debug
        #quiet
        ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!eNULL:!MD5:!DSS
        ssl-default-bind-options no-sslv3

defaults
 <niet relevant>


frontend webmail-http
        bind *:80
        bind *:443 ssl crt /data/ssl
        bind :::80
        bind :::443 ssl crt /data/ssl
        mode http
        default_backend dsapid
        log global
        redirect scheme https if !{ ssl_fc }
        capture request header  Host len 63
        http-response set-header Strict-Transport-Security  max-age=31536000

backend dsapid
        server local 127.0.0.1:8000

[ Voor 102% gewijzigd door CyBeR op 04-01-2016 18:57 ]

[8088]

CyBeR schreef op maandag 04 januari 2016 @ 18:55:
Voor A+ moet je HSTS headers meesturen, anders krijg je maximaal A.

Naast HSTS is volgens mij ook Forward Secrecy nodig voor een A+-waardering. Zo te zien wordt bij Alpha Bootis de cipherkeuze bij de browser gelegd, in plaats van dat de server voorkeur afdwingt. Om dit door Apache te laten forceren kun je SSLHonorCipherOrder op on zetten en de ciphers in de juiste volgorde zetten (met ECDHE en EDH vooraan).

Op Apache krijg ik met de volgende suite een A+:

SSLCipherSuite "SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"

(volgens mij heb ik die ooit van Mozilla geplukt)

Dus voor de volledigheid:

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"
Header always set Strict-Transport-Security "max-age=31536000"

[ Voor 21% gewijzigd door 8088 op 04-01-2016 19:31 ]

[Verwijderd]

Vooruit, ik hoor nu ook bij het A+ clubje. Als het zo makkelijk is om dat te regelen dan waarom niet.

[ Voor 40% gewijzigd door Verwijderd op 04-01-2016 20:33 ]

[azerty]

Verwijderd schreef op maandag 04 januari 2016 @ 20:31:
Vooruit, ik hoor nu ook bij het A+ clubje. Als het zo makkelijk is om dat te regelen dan waarom niet.

Een A+ behalen is inderdaad nog niet zo moeilijk, het is pas als je overal 100% wilt dat je wat concessies zult moeten gaan doen (vandaag mee lopen spelen )

[CyBeR]

Ja als je 100% wilt op alles moet je allerlei dingen doen waardoor je met redelijk gangbare browsers opeens niet meer compatibel bent, dus da's niet per see een goed idee

[Verwijderd]

Ik geloof op zich wel in iets "adequaat" beveiligen. Facebook scoort op zich ook maar een B bijvoorbeeld.
Je sluit natuurlijk ook wel gewoon alle enigszins verouderde software uit door links en rechts van alles uit te gaan zitten schakelen om dat testje tevreden te stellen... al valt ook daar meer dan genoeg voor te zeggen.
Als men op hun "toch nog werkende" XP machine en internet explorer 8 steeds meer sites tegenkomt die niet fatsoenlijk werken is er wellicht ook motivatie om iets actuelere software te gaan installeren.

[ Voor 24% gewijzigd door Verwijderd op 04-01-2016 22:06 ]

[begintmeta]

Doos SNI te gebruiken sluit je overigens ook de minder actuele software uit.

[Verwijderd]

JeroenED schreef op donderdag 02 april 2015 @ 17:06:
Mijn voornaamste vrees is dat de certificaten snel ongeldig zullen worden verklaard. Met een beetje technische kennis (Linux is niet zo moeilijk) kan je op 1,2,3 een certificaat genereren voor een domein waarlangs je dan met gemak tonnen spam mee kan versturen.

Wat heeft dat met het geldig of ongeldig zijn van die certificaten te maken? Mail gaat niet over https, voor zover ik weet.

[Luqq]

Hier een secure configuratie generator: https://mozilla.github.io...tls/ssl-config-generator/

[begintmeta]

Verwijderd schreef op dinsdag 05 januari 2016 @ 15:35:
.... Mail gaat niet over https, voor zover ik weet.

Mail (tussen mailservers) gaat doorgaans over SMTP, eventueel SMTPS, maar vaak (vaak ook niet trouwens) SMTP+TLS, dus dan heb je in principe wel sleutels nodig. Overigens controleren servers maar zelden de metadata van de sleutels van andere servers.

[CyBeR]

begintmeta schreef op dinsdag 05 januari 2016 @ 15:40:
[...]

Mail (tussen mailservers) gaat doorgaans over SMTP, eventueel SMTPS, maar vaak (vaak ook niet trouwens) SMTP+TLS, dus dan heb je in principe wel sleutels nodig. Overigens controleren servers maar zelden de metadata van de sleutels van andere servers.

s/zelden/nooit/ (tenzij expliciet overeen gekomen door handmatige configuratie)

Het alternatief is namelijk afleveren over smtp zonder tls, wat niet bepaald beter is.

[begintmeta]

CyBeR schreef op dinsdag 05 januari 2016 @ 15:44:
[...]


s/zelden/nooit/ (tenzij expliciet overeen gekomen door handmatige configuratie)

Het alternatief is namelijk afleveren over smtp zonder tls, wat niet bepaald beter is.

Alternatief zou je ook niet kunnen afleveren, maar je hebt gelijk dat mijn zelden inderdaad een beetje een understatement is.

[azerty]

CyBeR schreef op maandag 04 januari 2016 @ 22:02:
Ja als je 100% wilt op alles moet je allerlei dingen doen waardoor je met redelijk gangbare browsers opeens niet meer compatibel bent, dus da's niet per see een goed idee

Jup, inderdaad. Zit nu op het volgende:

100% Certificate
95% Protocol Support (TLS 1.0, 1.1 & 1.2)
100% Key Exchange
100 90% Cipher Strength

Werkt niet:
- Android 2.3.7
- IE 6, IE 8 op XP
- Java 6&7 in zijn geheel

Als je de 100% op Protocol wilt halen, dan geef je onder meer nog compatibiliteit op met Android < 4.4.2, IE 10 op windows phone 8, OpenSSL 0.9.8y, en Safari 5.1.9/6.0.4

100% op Cipher Strength is ook mogelijk, maar dan zonder AES-128, wat zoals hieronder aangehaald wordt dus niet ideaal is

Diegene die nu niet werken zijn geen probleem voor mij, de bovenstaande eigenlijk ook niet, maar ja, heb al meer dan de meeste anderen nu

[ Voor 8% gewijzigd door azerty op 05-01-2016 16:39 ]

[Osiris]

100 op cipher strength is mijns inziens niet aan te raden om na te streven. Dat houdt namelijk in dat je 128 bits GCM uitgezet hebt, waardoor bijv. Chrome terugvalt op 256 bits AES CBC (tenzij je wellicht ChaCha20/Poly1305 hebt? Maar dat zit nog niet in OpenSSL 1.0.2d). En CBC is een mode of operation waar recentelijk toch wel het e.e.a. aan op te merken is geweest security-wise en wat je een "obsolete cipher"-waarschuwing in Chrome oplevert.

Zelf heb ik 128 bit GCM toegevoegd zonder 128 bit CBC. Overigens heb ik sowieso een dikke vinger naar al die legacy browsers en OS-en:

code:

SSLCipherSuite "EECDH+AESGCM:EECDH+AES256 !DH !3DES !MEDIUM !LOW !aNULL !eNULL !LOW !RC4 !MD5 !EXP !PSK !SRP !DSS"

Enige wat ik toesta is:

• Ephemeral elliptic curve DH als key exchange (forward secrecy en de non-ECC EDH-browsers zijn niet relevant te noemen);
• AES GCM (128+256 bits) óf
• AES CBC (alléén 256 bits) met SHA384/SHA256/SHA1 als HMAC.

[ Voor 40% gewijzigd door Osiris op 05-01-2016 16:12 ]

[CyBeR]

begintmeta schreef op dinsdag 05 januari 2016 @ 15:47:
[...]

Alternatief zou je ook niet kunnen afleveren

Dat zou zo'n handmatige actie zijn. Niemand op het internet doet dat voor het generieke geval van e-mail die afgeleverd moet worden.

Een ander probleem overigens is wat stop je in de common name? De servernaam (zoals in MX record) of de domeinnaam waarnaar je probeert af te leveren? Of beide? Er is geen standaard voor.

Wel wordt er gewerkt aan een SMTP-versie van HSTS overigens.

[Osiris]

CyBeR schreef op dinsdag 05 januari 2016 @ 16:11:
[...]

Een ander probleem overigens is wat stop je in de common name? De servernaam (zoals in MX record) of de domeinnaam waarnaar je probeert af te leveren? Of beide? Er is geen standaard voor.

Even los van het feit dat de Common Name deprecated is en dat men zou moeten kijken naar de subjectAltNames heb ik er zelf voor gekozen om eigenlijk alles gelijk te trekken: de hostname van Postfix die in de banner terecht komt die je ziet als je connect is gelijk aan de hostname van 't MX-record en aan de DNS-naam in de SAN van het certificaat.

Leek me dat ik dan wel zo veilig mogelijk zit met eventuele spam-checks die vanalles willen checken

[azerty]

Osiris schreef op dinsdag 05 januari 2016 @ 16:09:
100 op cipher strength is mijns inziens niet aan te raden om na te streven. Dat houdt namelijk in dat je 128 bits GCM uitgezet hebt, waardoor bijv. Chrome terugvalt op 256 bits AES CBC (tenzij je wellicht ChaCha20/Poly1305 hebt? Maar dat zit nog niet in OpenSSL 1.0.2d). En CBC is een mode of operation waar recentelijk toch wel het e.e.a. aan op te merken is geweest security-wise en wat je een "obsolete cipher"-waarschuwing in Chrome oplevert.

Zelf heb ik 128 bit GCM toegevoegd zonder 128 bit CBC. Overigens heb ik sowieso een dikke vinger naar al die legacy browsers en OS-en:

code:

SSLCipherSuite "EECDH+AESGCM:EECDH+AES256 !DH !3DES !MEDIUM !LOW !aNULL !eNULL !LOW !RC4 !MD5 !EXP !PSK !SRP !DSS"

Enige wat ik toesta is:

• Ephemeral elliptic curve DH als key exchange (forward secrecy en de non-ECC EDH-browsers zijn niet relevant te noemen);
• AES GCM (128+256 bits) óf
• AES CBC (alléén 256 bits) met SHA384/SHA256/SHA1 als HMAC.

Jup, had niet op Chrome getest (gebruik ik zelf niet meer), maar je hebt gelijk... Laptop waar er wel nog Chrome op stond gaf idd "verouderde" cipher aan. Dan maar 90% ipv 100% voor de uitzonderlijke keer dat iemand met chrome op mijn webmail/cloud omgeving aan de slag moet

Edit: ik ga wel nog voor DH, maar dan met een custom set parameters van 4096 bit, zou voorlopig genoeg moeten zijn, en kan het dan in de toekomst nog steeds uitfaseren

[ Voor 5% gewijzigd door azerty op 05-01-2016 16:44 ]

[Osiris]

azerty schreef op dinsdag 05 januari 2016 @ 16:41:
[...]

Jup, had niet op Chrome getest (gebruik ik zelf niet meer), maar je hebt gelijk... Laptop waar er wel nog Chrome op stond gaf idd "verouderde" cipher aan. Dan maar 90% ipv 100% voor de uitzonderlijke keer dat iemand met chrome op mijn webmail/cloud omgeving aan de slag moet

Je moet je IMO simpelweg niet blindstaren op die 90/100 getalletjes van SSLLabs Hij checkt alleen 't aantal bits zonder rekening te houden met de mode of operation, wat natuurlijk niet helemaal kosher is.

Overigens zijn er ook reports dat de AES keying methods om tot een 256 bits key te komen niet 100 % kosher is, waardoor dat enigszins vulnerable is. Nu is dat tot nog toe alleen "hackable" (lees: 256 bit AES theoretisch sneller te kraken dan brute force 128 bit AES) bij een minder aantal "rounds" in het AES-proces dan het daadwerkelijk aantal rounds wat in de normaliter gebruikte AES-ciphers gebeurt, maar echt lekker is anders

Aangezien het dus (nog?) niet vulnerable is bij het volledige aantal rounds AES is het dus ook ernstig voorbarig om maar te roepen dat men dús maar geen 256 bits AES meer moet gebruiken, maar er zijn dus luitjes die dat (onterecht mijns inziens) roepen..

Bron

azerty schreef op dinsdag 05 januari 2016 @ 16:41:
[...]

Edit: ik ga wel nog voor DH, maar dan met een custom set parameters van 4096 bit, zou voorlopig genoeg moeten zijn, en kan het dan in de toekomst nog steeds uitfaseren

Niets mis met DH hoor (mits geen last van Logjam idd), maar 't heeft een nogal wat hogere performance dan z'n elliptic curve broertje

[ Voor 16% gewijzigd door Osiris op 05-01-2016 16:54 ]

[azerty]

Als er nog niet veel vervangers beschikbaar zijn die wijd inzetbaar zijn (zoals je aanhaalt dat ChaCha20/Poly1305 nog niet in die specifieke openSSL versie zit), wat moet je dan gaan gebruiken ipv aes-256?

Osiris schreef op dinsdag 05 januari 2016 @ 16:47:
[...]

Niets mis met DH hoor (mits geen last van Logjam idd), maar 't heeft een nogal wat hogere performance dan z'n elliptic curve broertje

Mijn voorrangslijstje is op dit moment als volgt:

EECDH+AESGCM > EDH+AESGCM > EECDH+AES256 > EDH+AES256 (en al de rest niet)

[ Voor 52% gewijzigd door azerty op 05-01-2016 17:10 ]

[Osiris]

azerty schreef op dinsdag 05 januari 2016 @ 16:52:
Als er nog niet veel vervangers beschikbaar zijn die wijd inzetbaar zijn (zoals je aanhaalt dat ChaCha20/Poly1305 nog niet in die specifieke openSSL versie zit), wat moet je dan gaan gebruiken ipv aes-256?

't Is (nog) niet vulnerable hè. Ik heb de bron erbij geëdit. Naast de originele paper (zie "UPDATED" onderaan), staat er ook een opsomming met "There are three reasons not to panic:"

Overigens zou je kunnen overstappen van OpenSSL naar LibreSSL, indien je distributie dat enigszins makkelijk mogelijk maakt. Ik heb er nog maar vluchtig naar gekeken en zit de voors en tegens af te wegen, maar volgens mij lopen ze enigszins voor qua ciphers, zoals ChaCha20/Poly1305.

azerty schreef op dinsdag 05 januari 2016 @ 16:52:
Mijn voorrangslijstje is op dit moment als volgt:

ECDH+GCM > DH+GCM > ECDH+AES256 > DH+AES256 (en al de rest niet)

Vreemd genoeg geeft dat in een `openssl ciphers -v 'ECDH+GCM:DH+GCM:ECDH+AES256:DH+AES256'` geen 128 bit GCM? Als ik van GCM -> AESGCM maak wel.. Raer..

[ Voor 18% gewijzigd door Osiris op 05-01-2016 17:01 ]

[CyBeR]

Osiris schreef op dinsdag 05 januari 2016 @ 16:47:
[...]

Overigens zijn er ook reports dat de AES keying methods om tot een 256 bits key te komen niet 100 % kosher is, waardoor dat enigszins vulnerable is. Nu is dat tot nog toe alleen "hackable" (lees: 256 bit AES theoretisch sneller te kraken dan brute force 128 bit AES) bij een minder aantal "rounds" in het AES-proces dan het daadwerkelijk aantal rounds wat in de normaliter gebruikte AES-ciphers gebeurt, maar echt lekker is anders

Aangezien het dus (nog?) niet vulnerable is bij het volledige aantal rounds AES is het dus ook ernstig voorbarig om maar te roepen dat men dús maar geen 256 bits AES meer moet gebruiken, maar er zijn dus luitjes die dat (onterecht mijns inziens) roepen..

Bron

Dat betreft een related-key attack en is weinig interessant als je gewoon fatsoenlijke keys gebruikt. Related-key betekent dat je meerdere keys gebruikt die slechts gedeeltelijk verschillen.

[Osiris]

CyBeR schreef op dinsdag 05 januari 2016 @ 16:58:
[...]


Dat betreft een related-key attack en is weinig interessant als je gewoon fatsoenlijke keys gebruikt. Related-key betekent dat je meerdere keys gebruikt die slechts gedeeltelijk verschillen.

Wordt inderdaad ook in de "three reasons not to panic" gemeld.

Overigens heb ik één certificaat van LE en da's een subdomein waarvan ik 't hoofddomein niet in eigen handen heb (vindt LE geen probleem..). Voor de rest van m'n domeinen wacht ik nog even op ECDSA en OCSP Must-Staple support.

[ Voor 31% gewijzigd door Osiris op 05-01-2016 17:03 ]

[azerty]

Osiris schreef op dinsdag 05 januari 2016 @ 16:56:
[...]

't Is (nog) niet vulnerable hè. Ik heb de bron erbij geëdit. Naast de originele paper (zie "UPDATED" onderaan), staat er ook een opsomming met "There are three reasons not to panic:"

Was een beetje een rhetorische vraag "Als niks veilig is, wat kun je dan gebruiken?"

Osiris schreef op dinsdag 05 januari 2016 @ 16:56:
Vreemd genoeg geeft dat in een `openssl ciphers -v 'ECDH+GCM:DH+GCM:ECDH+AES256:DH+AES256'` geen 128 bit GCM?

Bij mij geeft

code:

openssl ciphers -v 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH'

De volgende output:

ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384
ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1

[Osiris]

azerty schreef op dinsdag 05 januari 2016 @ 17:03:
Bij mij geeft

code:

openssl ciphers -v 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH'

De volgende output:

[...]

Ja bij mij ook maar die lijst met ciphers gaf je niet hè

Alsnog raar dat GCM en AESGCM 't onderscheid tussen resp. geen en wel 128 bits AES GCM maakt..

De man-page van `openssl ciphers` kent een losstaande GCM niet eens

[ Voor 28% gewijzigd door Osiris op 05-01-2016 17:07 ]

[azerty]

Note to self: beter opletten tijdens overtypen

[analog_]

Osiris schreef op dinsdag 05 januari 2016 @ 17:04:
[...]

Ja bij mij ook maar die lijst met ciphers gaf je niet hè

Alsnog raar dat GCM en AESGCM 't onderscheid tussen resp. geen en wel 128 bits AES GCM maakt..

De man-page van `openssl ciphers` kent een losstaande GCM niet eens

IIRC: de ene is AES-GCM waarbij gebruik gemaakt wordt van de ingebouwde HMAC container, de andere implementatie gebruikt AES-GCM puur als encryptie methode met een alternatieve HMAC implementatie voor authenticiteit en integriteit.

[Osiris]

AFAIK is GCM per definitie een AEAD.