Datenhaufen zu IT und Elektronik.

Kategorie: IT-Security (Seite 6 von 6)

Notizen & Praxis zur IT-Sicherheit – von Responsible Disclosure bis Härtung.

TLS 1.3 für Postfix & Dovecot: Einrichtung und Konfiguration​

Sowohl mein Postfix als auch der Dovecot sprechen nun sauber TLS 1.3.

Wenn Postfix sowie Dovecot sauber gegen OpenSSL 1.1.1 gebaut sind fehlen nur zwei Configänderungen.

Dovecot spricht es meist sofort wenn man hier die minimale TLS Version ind der 10-ssl.conf:

ssl_min_protocol = TLSv1.1

Beim Postfix setzt man einfach die zu nutzenden TLS Versionen in der main.cf:

smtpd_tls_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtp_tls_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtpd_tls_mandatory_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtp_tls_mandatory_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3

Schon spricht Postfix TLS 1.3 mit anderen Server und beide Dienste sind in der Lage dieses mit Clients zu sprechen!

Test für smtp:

$ openssl s_client -starttls smtp -crlf -connect smtp.kernel-error.de:25
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3944 bytes and written 404 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

Test für imap:

$ openssl s_client -connect imap.kernel-error.de:993 -crlf
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3944 bytes and written 404 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

So sieht ein Logfile doch schon viel mehr nach 2019 aus, oder?

Feb 15 16:05:43 smtp postfix/smtp[7475]: Verified TLS connection established to mx1.freebsd.org[2610:1c1:1:606c::19:1]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256

Bei Fragen, einfach fragen 🙂

Hardenize ein Security-Scanner für die Domain

Mir ist ein weiteres Onlinetool zum scannen seiner Domain durch den Browser gerutscht. https://www.hardenize.com/

Wie immer darf man nicht bild jedem Tool trauen und sich ohne denken darauf verlassen! Die Ergebnisse müssen immer mit dem nötigen Hintergrundwissen und Feingefühl interpretiert werden…. Hardenize testet nach der Eingabe einer Domain etwas umfassender. Es schaut sich die TLS Konfiguration der Webseite, sowie des Mailservers an. Prüft auf wichtige Policys, schaut in den DNS und bewertet somit etwas das Gesamtbild.

Vielleicht interessant für einen von euch.

Geht deine Domain am 01.02.2019 noch oder ist dein DNS kaputt?

Hey,

viele übersehen wohl gerade das es in drei Tagen ein Problem mit ihrem DNS und vor allem der Erreichbarkeit ihrer Zone geben könnte.

Testet doch einfach mal ob eure Domain/Zone ein Problem bekommt oder nicht >>klick<<

Es dreht sich alles darum, dass man entlich mal die „alten“ DNS Server aus dem Internet schieben möchte. Heise hat das ganz fein zusammengeschrieben: >>heise-klick<<

Oder halt direkt bei: https://dnsflagday.net/

Spannend wird es ab dem 01.02.2019. Wer also ab dann keine Stress habe möchte sollte vielleicht noch mal nachsehen?

Viel Spaß 😀

TLS 1.3 ist da!

Im August wurde TLS 1.3 auf der IETFE-Tagung als fertig beschlossen 😀 Damit haben sich aber alle wirklich Zeit gelassen! OpenSSL hat am 11.09.2018 die Version 1.1.1 (LTS) freigegeben. Am 12.09.2018 ist diese in die FreeBSD Ports gekommen und:

root@www:/ # /usr/local/bin/openssl version
OpenSSL 1.1.1 11 Sep 2018

Fehlt also nur noch ein Eintrag in der make.conf und schon lässt sich nginx sauber dagegen bauen und alles automatisch mit portmaster auf dem neusten Stand halten 🙂

/etc/make.conf
DEFAULT_VERSIONS+= ssl=openssl111

Schaut mal nach, die meisten machen wohl jetzt schon TLS 1.3 beim lesen dieser Zeilen ^^

Qualys und SSL Labs hängen leider noch etwas nach, hier wird noch auf/gegen die Draft Version geprüft (For TLS 1.3 tests, we currently support draft version 28.). Aber ich wette das wird nicht mehr lange dauern!

Kleines Update, die HIGH-TECH Bridge Jungs testen sauber auf TLS 1.3.

Ich wurde gerade drauf hingewiesen, dass die Developer Version von ssllabs TLS 1.3 schon sauber testet. Danke Jost 😀

https://dev.ssllabs.com/ssltest/analyze.html?d=www.kernel%2derror.de&s=2a01%3a4f8%3a161%3a3ec%3a0%3a0%3a0%3a443&hideResults=on&latest

Kein TLS 1.0 mehr

Da TLS 1.0 zum 30.06.2018 aus dem PCI Support fliegt (was nach knapp 19 Jahren auch mal ok ist), habe ich bei mir gerade überall den TLSv1.0 Support deaktiviert. Nein ich möchte nicht PCI konform sein… Damit sorge ich nun wieder einmal dafür, dass man mich mit einiger alter Software/Hardware und Betriebssystemen nicht mehr erreicht. Für mich ganz persönlich kann ich damit sehr gut leben 🙂 Wer jetzt noch mit so einer „Kiste“ unterwegs ist…. Na, der ist Kummer gewohnt!

Wen es interessiert der kann mit Qualys SSL Labs alles Mögliche scannen und auch direkt sehen welche Systeme wohl bei einem selbst nicht mehr funktionieren werden.

Zusätzlich spiele ich schon länger mit dem Gedanken bei meinem Mailserver Übertragungen ohne Transportverschlüsselung komplett zu verbieten. Für mich selbst kann ich es ja frei entscheiden. Lieber keine E-Mail als eine ohne Krypto! Ich werde mal auswerten wie denn das Verhältnis ist und welche E-Mails mich nicht mehr erreichen würden. Dann sehen wir mal weiter! Ich bin nur deswegen etwas zögerlich, weil mir in der Vergangenheit immer mal wieder Gegenstellen unter die Nase gekommen sind, bei welchen ich fest davon ausgegangen wäre, dass sie TLS einsetzten. Städte, Krankenhäuser, Ärzte, Schulen, IT-Security Dienstleister usw. usw… Hier scheint noch immer Unverständnis darüber zu herrschen, für was man denn wohl bitte dieses TLS braucht. Der Dienstleister meiner Heimatstadt begrüßt mich zumindest inzwischen mit einem Cisco Demo Zertifikat. *kopfschüttel* da hat der Admin nach meinen letzten Fragen zu dem Thema wohl den „security ON Button“ in seiner GUI gefunden O_o

Wobei… Mein Brötchengeber setzt auf einen eigenen Exchange Server bei welchem zuletzt 3DES Cipher abgeschaltet werden mussten. Das macht keinen Spaß und keinen Sinn. Windows-Admins scheinen hier schmerzfrei zu sein, hm?

TLS 1.3, das wäre ja mal was 🙂 ich warte schon mit schwitzigen Fingern. Zumindest sind wir schon mal bei Beta 5 (29.05.2018). Die Beta 1 vom 20.03 habe ich mir zuletzt in einer Jail angesehen und damit sehr zufrieden etwas herumprobiert. Für so etwas bin ich einfach zu ungeduldig. Ist das bei euch anders? Wollt ihr lieber noch TLSv1.0 haben?

TLS 1 ist tot und damit ist es dann jetzt weg, egal ob im stunnel:

;/usr/local/etc/stunnel/conf.d/tls.conf
[...]
options = NO_SSLv3
options = NO_TLSv1
ciphers = ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DHE-RSA-AES256-SHA256
[...]

Oder unter Postfix:

#/usr/local/etc/postfix/main.cf
[...]
smtp_tls_protocols = TLSv1.2, TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtp_tls_ciphers = high
smtp_tls_mandatory_exclude_ciphers = MD5, DES, ADH, RC4, PSD, SRP, 3DES, eNULL, aNULL
smtp_tls_exclude_ciphers = MD5, DES, ADH, RC4, PSD, SRP, 3DES, eNULL, aNULL
smtp_tls_security_level = dane
smtp_dns_support_level = dnssec
smtp_tls_loglevel = 1
smtp_tls_mandatory_protocols = TLSv1.2, TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtp_tls_mandatory_ciphers = high
tls_preempt_cipherlist = yes
tls_random_source = dev:/dev/urandom
smtpd_tls_loglevel = 1 
smtpd_tls_received_header = yes
smtpd_use_tls = yes
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_key_file = /usr/local/etc/postfix/postfix.key
smtpd_tls_cert_file = /usr/local/etc/postfix/postfix.pem
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_mandatory_exclude_ciphers = MD5, DES, ADH, RC4, PSD, SRP, 3DES, eNULL, aNULL
smtpd_tls_exclude_ciphers = MD5, DES, ADH, RC4, PSD, SRP, 3DES, eNULL, aNULL
smtpd_tls_mandatory_ciphers = high
smtpd_tls_ciphers = high
smtpd_tls_mandatory_protocols = TLSv1.2, TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtpd_tls_protocols = TLSv1.2, TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtpd_tls_dh1024_param_file = /usr/local/etc/postfix/dh2048.pem
[...]

Oder auch im Dovecot:

#/usr/local/etc/dovecot/conf.d/10-ssl.conf
[...]
ssl = required
ssl_dh_parameters_length = 4096
ssl_protocols = !SSLv3 !SSLv2 !TLSv1
ssl_cipher_list = AES128+EECDH:AES128+EDH
ssl_prefer_server_ciphers = yes
[...]

Selbstverständlich auch im Nginx:

#/usr/local/etc/nginx/nginx.conf
[...]
ssl_stapling on;
ssl_stapling_verify on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_ecdh_curve secp521r1:secp384r1:secp256k1;
ssl_dhparam /usr/local/etc/nginx/ssl/dhparam.pem;
ssl_protocols TLSv1.1 TLSv1.2;
[...]

Und so weiter und so weiter 🙂

TLS 1.0 nur noch bis 30. Juni 2018 im PCI-Support: Was du wissen musst

Hallo zusammen,

sicher ist das schon bekannt aber damit ich es auch einmal geschrieben habe. Das PCI hat eine Deadline zum 30 Juni 2018 für den Support von TLS 1.0 gesetzt.

TLS 1.0 ist ab dem Moment „noch“ so gut wie vorher und es sollte kein Problem für uns alle sein aber alles was PCI konform sein möchte darf ab dann kein TLS 1.0 mehr einsetzten.

https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls

Nicht das ich PCI konform wäre *lach* aber es ist bei mir deaktiviert:

https://www.ssllabs.com/ssltest/analyze.html?d=www.kernel%2derror.de&latest

https://www.htbridge.com/ssl/?id=Cq6PBF3g

So long….

IT Trends Sicherheit 2018 in Bochum

Ich bin heute der Einladung von TMR zu den IT Trends Sicherheit 2018 ins Stadion nach Bochum gefolgt.

Nach der Begrüßung und den Keynotes sitze ich nun im zweiten Vortrag meiner Wahl. Bisher alles ok, was mir aber wieder im direkten Vergleich zu einem Vortrag in Club oder einer OpenSource Messe auffällt ist dieser doch starke Eindruck einer Verkaufsveranstaltung. Ok das ist zu erwarten und auch in Ordnung. Auf vielen OpenSource Messe wandert es ebenfalls immer mehr in diese Richtung, es fällt mir nur gerade sehr auf.

Viele Informationen sind dennoch wertvoll und neue Kontakte können ebenfalls nicht schaden.

SSD Secure Erase mit FreeBSD: So löschst du deine SSD sicher

Um alle Daten einer SSD möglichst sicher zu löschen gibt es im ATA die Funktion: „ATA Secure Erase“. Möchte man nun seine SSD schnell und einfach von allen Daten befreien (dd mit Nullen ist ja eher eine schlechte und nicht funktionsfähige Möglichkeit bei SSDs), nutzt man einfach diese Funktion.

Bei einem FreeBSD sieht dieses unter optimalen Bedingungen wie folgt aus:

root@sun-wks:/usr/home/kernel # camcontrol security ada4 -s Erase -e Erase
pass7: <OCZ-AGILITY3 2.15> ATA8-ACS SATA 3.x device
pass7: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)

You are about to ERASE ALL DATA from the following device:
pass7,ada4: <OCZ-AGILITY3 2.15> ATA8-ACS SATA 3.x device

Are you SURE you want to ERASE ALL DATA? (yes/no) yes
Issuing SECURITY_SET_PASSWORD password='Erase', user='master', mode='high'
Issuing SECURITY_ERASE_PREPARE
Issuing SECURITY_ERASE_UNIT password='Erase', user='master'

Erase Complete

Optimale Bedingungen?

Das eine oder andere BIOS „schützt“ die Festplatten vor dieser Funktion und sorgt dafür das sie nicht genutzt werden kann. Hier hilft es die Platte erst nach dem Boot anzuschließen. Um die Funktion nutzen zu können muss der SSD ebenfalls erst ein Kennwort gegeben werden. Ohne gesetztes Kennwort kann die Funktion ebenfalls nicht genutzt werden. Ich habe dieses in einem Abwasch erledigt indem ich erst das Kennwort und dann direkt die Funktion mit dem gesetzten Kennwort aufrufe (-s Erase -e Erase) Erase ist also in meinem Beispiel das gesetzte Kennwort.

Da wir gerade dabei sind… Viele SSDs habe eine Art „Selbstheilungsmodus“… Ist diese aktiviert prüft sich die SSD selbst und repariert sich, soweit möglich. Dieser Modus wird aktiviert wenn die SSD am Strom aber nicht am Datenbus angeschlossen ist. Bedeutet. SATA/SAS Kabel abziehen. Strom anschließen/einschalten und warten. In der Regel sollten SSDs nach knapp 4 Stunden mit ihrer „Selbstheilung“ fertig sein. Dieses lässt sich natürlich im Anschluss noch einmal wiederholen. Funktioniert die SSD nach zwei Durchläufen noch nicht wie gewünscht, wird sie wohl wirklich kaputt sein.

Fragen? Dann Fragen 😀

DNS über TLS mit Stunnel und BIND9 einrichten: Anleitung für mehr Sicherheit

Ihr erinnert euch an meine Ankündigung über TLS an meinem DNS vor ein paar Tagen? RFC 7858 – DNS over Transport Layer Security

Bei mir ist inzwischen recht oft die Frage nach dem „Wie“ angekommen. Nun ich habe dafür stunnel benutzt. stunnel ist nicht speziell für DNS sondern ist ein Stück Software welches sich vor Dienste schalten lässt die keine oder eine schlechte Implementierung für SSL/TLS haben. Eine komplett stumpfe Konfiguration um zu testen würde zum Beispiel auf einem FreeBSD wie folgt aussehen:

/usr/local/etc/stunnel/conf.d/dnstls.conf

[dns4]
accept = 853
connect = 5.9.24.235:53
cert = /usr/local/etc/stunnel/ssl/dns.crt
key = /usr/local/etc/stunnel/ssl/dns.key
CAfile = /usr/local/etc/stunnel/ssl/ca.crt


[dns6]
accept = :::853 connect = 5.9.24.235:53
cert = /usr/local/etc/stunnel/ssl/dns.crt
key = /usr/local/etc/stunnel/ssl/dns.key
CAfile = /usr/local/etc/stunnel/ssl/ca.crt 

So gestartet lässt sich eine TLS Verbinung zu Port 853 aufbauen und stunnel schiebt dann alles einfach weiter an den Bind auf Port 53. Ob eine SSL/TLS Verbindung aufgebaut werden kann testet man am besten mit openSSL: openssl s_client -connect ns1.kernel-error.de:853 -showcerts Ich werfe weiter unten mal den kompletten Output in den Post…

Um eine komplette DNS Abfrage über TLS zu prüfen nutze ich gerne getdns_query. Dieses ist bereits in den FreeBSD Ports. Ein Test würde wie folgt aussehen: getdns_query @5.9.24.235 -s -a -A -l L www.kernel-error.de AAAA die Option „-l L“ weißt getdns_query dabei an es per TLS zu probieren. Auch hier werde ich den kompletten Output weiter untem im Post zeigen.

Der versprochene openSSL Output

kernel@s-meer-bsd ~> openssl s_client -connect ns1.kernel-error.de:853 -showcerts
CONNECTED(00000003)
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = AlphaSSL CA - SHA256 - G2
verify return:1
depth=0 OU = Domain Control Validated, CN = *.kernel-error.de
verify return:1
---
Certificate chain
 0 s:/OU=Domain Control Validated/CN=*.kernel-error.de
   i:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
-----BEGIN CERTIFICATE-----
MIIIVjCCBz6gAwIBAgIMKHSoWgqp4f0QDMWoMA0GCSqGSIb3DQEBCwUAMEwxCzAJ
BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIwIAYDVQQDExlB
bHBoYVNTTCBDQSAtIFNIQTI1NiAtIEcyMB4XDTE3MDMxMDEwNTI1MloXDTE4MDMx
MTEwNTI1MlowPzEhMB8GA1UECxMYRG9tYWluIENvbnRyb2wgVmFsaWRhdGVkMRow
GAYDVQQDDBEqLmtlcm5lbC1lcnJvci5kZTCCAiIwDQYJKoZIhvcNAQEBBQADggIP
ADCCAgoCggIBAMtVm/TykTvxvwZN0h6H2YeIeu4G+scVCb+kxxa8Jrua7DuLchjm
05wj6zPTe+2opDNNeZ6T5/ISSKczUQO4p+ttxFzl8OGA8FaZe4Qc9FNYdzY35w2d
oMgpTpsO+xTEdLHbXcNvEdFXg/8vyKS5y9Ddp8mSvz/Mt04rj2sjXGWwV00ImDQ1
DHBEuNuvFsnyaXQkDXeC3bA+2EkuVIcFcviQT5At88CDLkP8ygJsD3iDudnVeEJZ
N1AFnjN/qQksjKvT5V75R7GcIhA0a6lC56iBmEykht8YdPy63940hYmO4Ug17p68
7uiPZKUsFkGmYchbkiw5KLTck6VVv9b5Z+lFfIQcfBf5blmaUkQQ8CP3yXXajmfP
3KqJu5c+M3OW9evFiE+z7ihtKVtOHQS86z0ijvSNaCfj9OWQKXhBzBzdEGTogC7n
Iq8YYjveRQ+ExffM+RY3xaqMc1368tUx6ir+0LdGiqgzDC5OcWPqRTNobeTfcETz
VCxqgTfVr4tDNTk1+LmRsWKVDuBtG3p/lJEwCU1z6ZP6xmNTBZc1iOuNOJN+CmYW
ZpKaI3F6JPRK4G2Hu4fa0GWjRHSSZYFkyBl520a8fTMGIY8JlfHfx9HVK2fFJ4yP
NxKligKSydphqEG8cyEU/V3oRlgZ7en1HmrWRrIRiWcmWk3qKl/AZk97AgMBAAGj
ggRDMIIEPzAOBgNVHQ8BAf8EBAMCBaAwgYkGCCsGAQUFBwEBBH0wezBCBggrBgEF
BQcwAoY2aHR0cDovL3NlY3VyZTIuYWxwaGFzc2wuY29tL2NhY2VydC9nc2FscGhh
c2hhMmcycjEuY3J0MDUGCCsGAQUFBzABhilodHRwOi8vb2NzcDIuZ2xvYmFsc2ln
bi5jb20vZ3NhbHBoYXNoYTJnMjBXBgNVHSAEUDBOMEIGCisGAQQBoDIBCgowNDAy
BggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9y
eS8wCAYGZ4EMAQIBMAkGA1UdEwQCMAAwPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDov
L2NybDIuYWxwaGFzc2wuY29tL2dzL2dzYWxwaGFzaGEyZzIuY3JsMC0GA1UdEQQm
MCSCESoua2VybmVsLWVycm9yLmRlgg9rZXJuZWwtZXJyb3IuZGUwHQYDVR0lBBYw
FAYIKwYBBQUHAwEGCCsGAQUFBwMCMB0GA1UdDgQWBBSL6GOdfjNSVXP7NNrKRfN/
ZEGEJTAfBgNVHSMEGDAWgBT1zdU8CFD5ak86t5faVoPmadJo9zCCAm0GCisGAQQB
1nkCBAIEggJdBIICWQJXAHUAu9nfvB+KcbWTlCOXqpJ7RzhXlQqrUugakJZkNo4e
0YUAAAFat9mThAAABAMARjBEAiBA/XALdgdBZzdvL20DwfeGUAKVhFAueJG6hIWF
eooeSwIgBAMtgDdRxtSkDbKZdkuT9pul6HlZgGSKBLwHjt08rSAAdgDd6x0reg1P
piCLga2BaHB+Lo6dAdVciI09EcTNtuy+zAAAAVq32ZOaAAAEAwBHMEUCIAwdq+Ma
WZ+v8TuKuwIT9oTHT6mlOuov2brZHNa53o5MAiEAq1ZFktpd5XzJQixebUuaCNKW
dZWUF58tKuB4l7xvGOUAdgCkuQmQtBhYFIe7E6LMZ3AKPDWYBPkb37jjd80OyA3c
EAAAAVq32ZZ1AAAEAwBHMEUCIAUVh0ZRcb/+WRb9F+nn/Jmzvgs/bnLQNwEjBUT1
/t2aAiEAmZWAnrB3RnsCbedw8SOvJk6HsZG67T0fdI96M/Pc47kAdgBWFAaaL9fC
7NP14b1Esj7HRna5vJkRXMDvlJhV1onQ3QAAAVq32Za/AAAEAwBHMEUCIQD92ZOc
1xqff1TJ7gsw/ZGtkvzrjIW6uu/Hu7ZxBKkOgQIgRC0TkK19+m8nUN7KDCqyKsZT
DqUrKE01MuPhx1RnIPMAdgDuS723dc5guuFCaR+r4Z5mow9+X7By2IMAxHuJeqj9
ywAAAVq32ZllAAAEAwBHMEUCIQCPAWIduEfXjVVq+qKHEtoy84Nqm+PsibSk8uXq
ziMziQIgJp3NRvIM8bFtzQe/ZQYBnNv2H3MwZmldaIbV5VcbMOQwDQYJKoZIhvcN
AQELBQADggEBAKmQsE/CjF2nRuqaPZht7EFsQpHzihm+VBA48HDN0Uj9JpObHadg
kxNunKd3K+KNsZP4gwg8Z+LfNAU2smK//Ptq7S/y3ECZTniwLMNx4ogekIuQ9i6a
5zgdN3TpWMV/pu2PEguG/FhDIeIEoC5L7qYAKsSq/4VMexUeVfg3IDbdFH0FGlF7
NRAvfY8KfkvkM6c0VhkAuisnYpt+N3RoXOUlQEbv2qRPikiRnLW4hyms0Y73W5v2
GBA6H66lPIqWTzalY9d1kUVY0N+qz/ZgZhdY0LkeTHG4l+XAyKwa241LHGtDHz7m
7c9LBqS3mXSFvfCL9eU2vzDHkU6cMixjf94=
-----END CERTIFICATE-----
 1 s:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
-----BEGIN CERTIFICATE-----
MIIETTCCAzWgAwIBAgILBAAAAAABRE7wNjEwDQYJKoZIhvcNAQELBQAwVzELMAkG
A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jv
b3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw0xNDAyMjAxMDAw
MDBaFw0yNDAyMjAxMDAwMDBaMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i
YWxTaWduIG52LXNhMSIwIAYDVQQDExlBbHBoYVNTTCBDQSAtIFNIQTI1NiAtIEcy
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2gHs5OxzYPt+j2q3xhfj
kmQy1KwA2aIPue3ua4qGypJn2XTXXUcCPI9A1p5tFM3D2ik5pw8FCmiiZhoexLKL
dljlq10dj0CzOYvvHoN9ItDjqQAu7FPPYhmFRChMwCfLew7sEGQAEKQFzKByvkFs
MVtI5LHsuSPrVU3QfWJKpbSlpFmFxSWRpv6mCZ8GEG2PgQxkQF5zAJrgLmWYVBAA
cJjI4e00X9icxw3A1iNZRfz+VXqG7pRgIvGu0eZVRvaZxRsIdF+ssGSEj4k4HKGn
kCFPAm694GFn1PhChw8K98kEbSqpL+9Cpd/do1PbmB6B+Zpye1reTz5/olig4het
ZwIDAQABo4IBIzCCAR8wDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C
AQAwHQYDVR0OBBYEFPXN1TwIUPlqTzq3l9pWg+Zp0mj3MEUGA1UdIAQ+MDwwOgYE
VR0gADAyMDAGCCsGAQUFBwIBFiRodHRwczovL3d3dy5hbHBoYXNzbC5jb20vcmVw
b3NpdG9yeS8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWdu
Lm5ldC9yb290LmNybDA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAGGIWh0dHA6
Ly9vY3NwLmdsb2JhbHNpZ24uY29tL3Jvb3RyMTAfBgNVHSMEGDAWgBRge2YaRQ2X
yolQL30EzTSo//z9SzANBgkqhkiG9w0BAQsFAAOCAQEAYEBoFkfnFo3bXKFWKsv0
XJuwHqJL9csCP/gLofKnQtS3TOvjZoDzJUN4LhsXVgdSGMvRqOzm+3M+pGKMgLTS
xRJzo9P6Aji+Yz2EuJnB8br3n8NA0VgYU8Fi3a8YQn80TsVD1XGwMADH45CuP1eG
l87qDBKOInDjZqdUfy4oy9RU0LMeYmcI+Sfhy+NmuCQbiWqJRGXy2UzSWByMTsCV
odTvZy84IOgu/5ZR8LrYPZJwR2UcnnNytGAMXOLRc3bgr07i5TelRS+KIz6HxzDm
MTh89N1SyvNTBCVXVmaU6Avu5gMUTu79bZRknl7OedSyps9AsUSoPocZXun4IRZZ
Uw==
-----END CERTIFICATE-----
---
Server certificate
subject=/OU=Domain Control Validated/CN=*.kernel-error.de
issuer=/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 4014 bytes and written 433 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: B1956B432DABE228C78E756329A796FA56C9646BE64326F8F96782BD946CCA82
    Session-ID-ctx: 
    Master-Key: 10329FBAE32471FC56D45E0AA0971CF5EB7977F7569AE4079219D9438E7A0F9DA8EC4150D9A074FC0AD8E63E00849047
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1513937385
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

Der versprochene getdns_query Output:

kernel@s-meer-bsd ~> getdns_query @5.9.24.235 -s -a -A -l L www.kernel-error.de AAAA
{
  "answer_type": GETDNS_NAMETYPE_DNS,
  "canonical_name": <bindata for www.kernel-error.de.>,
  "just_address_answers":
  [
    {
      "address_data": <bindata for 2a01:4f8:161:3ec::443>,
      "address_type": <bindata of "IPv6">
    },
    {
      "address_data": <bindata for 5.9.24.250>,
      "address_type": <bindata of "IPv4">
    }
  ],
  "replies_full":
  [
     <bindata of 0xd3578500000100010003000703777777...>,
     <bindata of 0xe9288500000100010003000703777777...>
  ],
  "replies_tree":
  [
    {
      "additional":
      [
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns1.kernel-error.de.>,
          "rdata":
          {
            "ipv4_address": <bindata for 5.9.24.235>,
            "rdata_raw": <bindata of 0x050918eb>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_A
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns2.kernel-error.org.>,
          "rdata":
          {
            "ipv4_address": <bindata for 176.9.109.53>,
            "rdata_raw": <bindata of 0xb0096d35>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_A
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns3.kernel-error.com.>,
          "rdata":
          {
            "ipv4_address": <bindata for 203.137.119.119>,
            "rdata_raw": <bindata of 0xcb897777>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_A
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns1.kernel-error.de.>,
          "rdata":
          {
            "ipv6_address": <bindata for 2a01:4f8:161:3ec::53>,
            "rdata_raw": <bindata of 0x2a0104f8016103ec0000000000000053>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_AAAA
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns2.kernel-error.org.>,
          "rdata":
          {
            "ipv6_address": <bindata for 2a01:4f8:150:1095::53>,
            "rdata_raw": <bindata of 0x2a0104f8015010950000000000000053>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_AAAA
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns3.kernel-error.com.>,
          "rdata":
          {
            "ipv6_address": <bindata for 2001:310:6000:f::1fc7:1>,
            "rdata_raw": <bindata of 0x200103106000000f000000001fc70001>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_AAAA
        },
        {
          "do": 0,
          "extended_rcode": 0,
          "rdata":
          {
            "rdata_raw": <bindata of 0x>
          },
          "type": GETDNS_RRTYPE_OPT,
          "udp_payload_size": 4096,
          "version": 0,
          "z": 0
        }
      ],
      "answer":
      [
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for www.kernel-error.de.>,
          "rdata":
          {
            "ipv6_address": <bindata for 2a01:4f8:161:3ec::443>,
            "rdata_raw": <bindata of 0x2a0104f8016103ec0000000000000443>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_AAAA
        }
      ],
      "answer_type": GETDNS_NAMETYPE_DNS,
      "authority":
      [
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for kernel-error.de.>,
          "rdata":
          {
            "nsdname": <bindata for ns2.kernel-error.org.>,
            "rdata_raw": <bindata for ns2.kernel-error.org.>
          },
          "ttl": 86400,
          "type": GETDNS_RRTYPE_NS
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for kernel-error.de.>,
          "rdata":
          {
            "nsdname": <bindata for ns1.kernel-error.de.>,
            "rdata_raw": <bindata of 0x036e7331c010>
          },
          "ttl": 86400,
          "type": GETDNS_RRTYPE_NS
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for kernel-error.de.>,
          "rdata":
          {
            "nsdname": <bindata for ns3.kernel-error.com.>,
            "rdata_raw": <bindata for ns3.kernel-error.com.>
          },
          "ttl": 86400,
          "type": GETDNS_RRTYPE_NS
        }
      ],
      "canonical_name": <bindata for www.kernel-error.de.>,
      "header":
      {
        "aa": 1,
        "ad": 0,
        "ancount": 1,
        "arcount": 7,
        "cd": 0,
        "id": 54103,
        "nscount": 3,
        "opcode": GETDNS_OPCODE_QUERY,
        "qdcount": 1,
        "qr": 1,
        "ra": 0,
        "rcode": GETDNS_RCODE_NOERROR,
        "rd": 1,
        "tc": 0,
        "z": 0
      },
      "question":
      {
        "qclass": GETDNS_RRCLASS_IN,
        "qname": <bindata for www.kernel-error.de.>,
        "qtype": GETDNS_RRTYPE_AAAA
      }
    },
    {
      "additional":
      [
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns1.kernel-error.de.>,
          "rdata":
          {
            "ipv4_address": <bindata for 5.9.24.235>,
            "rdata_raw": <bindata of 0x050918eb>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_A
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns2.kernel-error.org.>,
          "rdata":
          {
            "ipv4_address": <bindata for 176.9.109.53>,
            "rdata_raw": <bindata of 0xb0096d35>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_A
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns3.kernel-error.com.>,
          "rdata":
          {
            "ipv4_address": <bindata for 203.137.119.119>,
            "rdata_raw": <bindata of 0xcb897777>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_A
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns1.kernel-error.de.>,
          "rdata":
          {
            "ipv6_address": <bindata for 2a01:4f8:161:3ec::53>,
            "rdata_raw": <bindata of 0x2a0104f8016103ec0000000000000053>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_AAAA
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns2.kernel-error.org.>,
          "rdata":
          {
            "ipv6_address": <bindata for 2a01:4f8:150:1095::53>,
            "rdata_raw": <bindata of 0x2a0104f8015010950000000000000053>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_AAAA
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns3.kernel-error.com.>,
          "rdata":
          {
            "ipv6_address": <bindata for 2001:310:6000:f::1fc7:1>,
            "rdata_raw": <bindata of 0x200103106000000f000000001fc70001>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_AAAA
        },
        {
          "do": 0,
          "extended_rcode": 0,
          "rdata":
          {
            "rdata_raw": <bindata of 0x>
          },
          "type": GETDNS_RRTYPE_OPT,
          "udp_payload_size": 4096,
          "version": 0,
          "z": 0
        }
      ],
      "answer":
      [
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for www.kernel-error.de.>,
          "rdata":
          {
            "ipv4_address": <bindata for 5.9.24.250>,
            "rdata_raw": <bindata of 0x050918fa>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_A
        }
      ],
      "answer_type": GETDNS_NAMETYPE_DNS,
      "authority":
      [
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for kernel-error.de.>,
          "rdata":
          {
            "nsdname": <bindata for ns2.kernel-error.org.>,
            "rdata_raw": <bindata for ns2.kernel-error.org.>
          },
          "ttl": 86400,
          "type": GETDNS_RRTYPE_NS
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for kernel-error.de.>,
          "rdata":
          {
            "nsdname": <bindata for ns1.kernel-error.de.>,
            "rdata_raw": <bindata of 0x036e7331c010>
          },
          "ttl": 86400,
          "type": GETDNS_RRTYPE_NS
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for kernel-error.de.>,
          "rdata":
          {
            "nsdname": <bindata for ns3.kernel-error.com.>,
            "rdata_raw": <bindata for ns3.kernel-error.com.>
          },
          "ttl": 86400,
          "type": GETDNS_RRTYPE_NS
        }
      ],
      "canonical_name": <bindata for www.kernel-error.de.>,
      "header":
      {
        "aa": 1,
        "ad": 0,
        "ancount": 1,
        "arcount": 7,
        "cd": 0,
        "id": 59688,
        "nscount": 3,
        "opcode": GETDNS_OPCODE_QUERY,
        "qdcount": 1,
        "qr": 1,
        "ra": 0,
        "rcode": GETDNS_RCODE_NOERROR,
        "rd": 1,
        "tc": 0,
        "z": 0
      },
      "question":
      {
        "qclass": GETDNS_RRCLASS_IN,
        "qname": <bindata for www.kernel-error.de.>,
        "qtype": GETDNS_RRTYPE_A
      }
    }
  ],
  "status": GETDNS_RESPSTATUS_GOOD
}

Oh und weil ich gerade dabei war… Ich habe direkt ns2.kernel-error.org mit einem gültigen Zertifikat ausgestattet.

Fragen? Dann fragen 🙂

Neuere Beiträge »

© 2025 -=Kernel-Error=-

Theme von Anders NorénHoch ↑