Mit ‘ssl’ Tagged einträge

Transport Verschlüsselung E-Mail Provider

Samstag, Oktober 1st, 2016

Da Stiftung Warentest aktuell die erneuten Tests für E-Mail Server heraus gibt, habe ich mir mal die Mühe gemacht, die Transport Verschlüsselung auf unseren E-Mail Servern herauszufiltern um diese nach Ihrer ciphers zu untersuchen. Spannend war, dass mittlerweile alle eingehenden Verbindungen eine Recht hohe Sicherheit aufwiesen. Microsofts hotmail.com outlook.com so wie Mail.de waren die einzigsten, die noch ein CBS Mode verwenden. Alle anderen sind schon auf den neuen GCM Mode umgestiegen. Bei web.de, mail.de und mailbox.org haben anscheinend unersichtliche Server Infrastruktur die mit unterschiedlichen ciphers E-Mails Ausliefern.

google.com
ECDHE-RSA-AES128-GCM-SHA256

yahoodns.net
ECDHE-RSA-AES128-GCM-SHA256

t-online.de
ECDHE-RSA-AES256-GCM-SHA384

gmx.net und gmx.de
DHE-RSA-AES256-GCM-SHA384

web.de
DHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384

hotmail.com
ECDHE-RSA-AES256-SHA384

outlook.com
ECDHE-RSA-AES256-SHA384

freenet.de
DHE-RSA-AES256-GCM-SHA384

icloud.com
ECDHE-RSA-AES128-GCM-SHA256

mail.de
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA256
ECDHE-RSA-AES256-GCM-SHA384

mailbox.org
DHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384

posteo.de
ECDHE-RSA-AES256-GCM-SHA384

Die Resultate habe ich unter 100.000 E-Mailserver-Verbindungen der letzten Woche herauszufiltern. Sortiert sind die aufrufe nach Anzahl der Verbindungen wobei die Anzahl der letzten 3 Anbieter < 1% liegt.

Ohje, alles gepacht und doch verwundbar

Dienstag, November 18th, 2014

Es reicht nicht aus nur Updates einzuspielen, wenn man Dienste nicht neu startet deren libraries aktualisiert wurden. Denn erst nach einem Neustart werden diese neu eingelesen.

lsof | grep libssl | grep DEL
apache2 1129 www-data DEL REG 253,1 1831551 /lib/x86_64-linux-gnu/libssl.so.1.0.0

Ein einfacher Neustart der hier aufgeführten Dienstes reicht in diesem Fall aus.
/etc/init.d/apache restart

speedport.ip 403 permission to get this page

Mittwoch, Dezember 12th, 2012

Heute mussten wir bei einem Kunden das WLAN auf seinem neuen DSL Router einstellen. Hierfür habe ich den Port auf meinen Rechner durch leiten wollen:

ssh -L 8080:192.168.2.1:443 hostname-client

Dann haben wir aber eine 403 Error bekommen:
403 Forbidden
Your client does not have permission to get this page.(code=41193) from this server.

Also habe ich in der /etc/hosts auf meinem localen Rechner den Namen des Routers Nachgetragen:
127.0.0.1 speedport.ip

Dann habe ich den SSH Befehl noch um sudo erweitert um den Port 443 (SSL) bei mir auch local zu binden.
sudo -i ./id_rsa ssh -L 443:192.168.2.1:443 hostname-client

Eine eigene x509v3 CA erstellen

Samstag, April 28th, 2012

Zunächst wird eine Config Datei benötigt.
ca.conf:
[ req ]
default_bits=4096
default_md=sha512
utf8=yes
distinguished_name=req_distinguished_name
x509_extensions=x509_exts

[ req_distinguished_name ]

[ x509_exts ]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
basicConstraints = CA:true

[ ca ]
default_ca=default_ca

[ default_ca ]
certificate=ca.crt
private_key=private/ca.key
default_days=36500
default_md=sha512
database=meta/db.txt
unique_subject=no
serial=meta/serial
policy=ca_policy
name_opt=ca_default
cert_opt=ca_default
copy_extensions=copyall
x509_extensions=ca_x509_ext

[ ca_x509_ext ]
# an empty referenced section ensures a v3 cert is generated

[ server ]
nsCertType=server

[ ca_policy ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = optional
emailAddress = optional

Dann werden noch ein paar Ordner, eine lehre Datenbank(halde) und eine Seriennummer benötigt.
mkdir private meta certs
touch meta/db.txt
echo 01 > meta/serial

Nun wird die CA erstellt.
openssl req -x509 -subj /CN=TestCA -newkey rsa:4096 -keyout private/ca.key -out ca.crt -nodes -config ca.conf -days 36500

Dann muss das CSR (Certifikate signing request) erstellt werden.
openssl req -subj /CN=TestCert -newkey rsa:4096 -keyout new.key -out new.csr -nodes -config ca.conf -days 36500

Zum Schluss wird aus dem CSR das von der CA signierte Zertifikat des Clients.
openssl ca -in new.csr -outdir certs/ -config ca.conf -notext -utf8

Möchten man nun z.b. ein vpn Server mit der CA betreiben braucht man noch ein Server Zertifikat.
openssl ca -in new.csr -outdir certs/ -config ca.conf -extensions server -notext -utf8
(z.B. openvpn server wenn man die –ns-cert-type server bei den clients angibt)

Die Zertifikate kann man sich dann mit folgenden Befehl anzeigen lassen.
openssl x509 -in ca.crt -noout -text

Quelle: www.openssl.org

[update 17.02.2014]
Der Hash Algorithmus wurde von sha1 auf sha512 geändert, da dieser als Angreifbar gilt.

Keine Blacklist für 4096bit Keys

Samstag, Oktober 18th, 2008

Ich weiß ja das 4096bit große Keys übertrieben sind. Aber das ist doch kein Grund dafür keine Blacklist anzulegen. So bekam ich immer die folgende Fehlermeludung wenn ich die OpenVPN verbindung starten wollte:

user@server:~# /etc/init.d/openvpn start
* Starting virtual private network daemon.
WARN: could not open database for 4096 bits. Skipped
* client (OK) [ OK ]

Da ich mir ja sicher bin das mein Key richtig ist habe ich einfach eine lehre Blacklist angelegt.
touch /usr/share/openssl-blacklist/blacklist.RSA-4096

user@server:~# /etc/init.d/openvpn stop
* Stopping virtual private network daemon. [ OK ]
user@server:~# /etc/init.d/openvpn start
* Starting virtual private network daemon.
* client (OK)

Quelle: forum.ubuntuusers.de