Mein Datenhaufen zu IT und Elektronik Themen.

Schlagwort: Security (Seite 3 von 4)

DNS über TLS mit stunnel und Bind9

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 🙂

DNSsec, DANE; TLSA, Postfix… Was ist da gerade los?

Man man man… Was ist denn da passiert? Seit 3 oder 4 Tagen scheint das Thema im Internet irgendwie besonders aktiv zu sein, oder? Nur warum?!?!

Plötzlich bekomme ich nicht nur jeden Tag einen Haufen Anfragen zu dem Thema, viel scheinen auch irgendwas testen zu wollen und pumpen E-Mails mit Random-Empfängern an meine Domains….

Im Grunde habe ich ja nichts gegen Tests. Nur grob abgesprochen wäre schon schön, mein Monitoring wird sonst immer so „wuschig“! 😀

Um noch mal ein paar Themen zusammen zu fassen:

1. Basis von allem ist DNSsec
2. TLSA Records „ist DANE“
3. Postfix kann TLSA Records auswerden, ohne selbst welche für sein System zu haben.

Mein kleines DNSSEC Howto

DNSSEC und DNS-based Authentication of Named Entities (DANE)

Postfix SSL/TLS gesichert mit TLSA / DANE und DNSSEC

DNSSEC fähiger Registrar

TLSA / DANE RECORD von Hand manuel prüfen.

So long…

Neue dnssec KSKs

Ich habe nach längerem dann mal meinen KSK für´s dnssec getauscht. Bzw. ich bin gerade dabei 🙂

Der alte war noch ein 1024bit NSEC3RSASHA1. Jetzt ist auch klar warum er getauscht werden musste 😛 Der neue ist nun ein NSEC3RSASHA1 mit 4096bit. Als zweiten neuen Key habe ich einen RSASHA512 mit ebenfalls 4096bit erstellt. So habe ich für den Fall der Fälle auch direkt einen ohne SHA1 im „Anschlag“.

Dieser neue Key ersetzt in Kürze den alten 1024bit KSK Schlüssel. Bereits jetzt sollte es aber für jeden nur noch über den 4096bit NSEC3RSASHA1 Schlüssel laufen.

Inzwischen sollte wohl jede halbwegs aktuelle Software mit dnssec Support mit diesen Schlüsseln umgehen können. Wenn nicht, wird es Zeit für ein Update 😀

In diesem Sinne!


* U-P-D-A-T-E *

Inzwischen ist auch der andere Schlüssel oben und sollte sich so langsam durch die Welt sprechen….

http://dnsviz.net/d/kernel-error.de/dnssec/

http://dnsviz.net/d/kernel-error.org/dnssec/

http://dnsviz.net/d/kernel-error.com/dnssec/

DNSSEC fähiger Registrar

In der letzten Zeit häufen sich bei mir die Anfragen, mit welchem Registart ist zusammenarbeite. Vor allem im Hinblick auf DNSSEC und dem KSK oder besser der DS-RECORDS.

Hier kann und möchte ich gerne die SpeedPartner GmbH aus Neuss empfehlen. Hier arbeite ich gerne mit dem Herrn Metz zusammen. Es ist immer jemand erreichbar, vor allem lassen sich schnell und einfach auch etwas ungewöhnliche Dinge umsetzten. Zwar ist das Webinterface (stand 06.2014) noch nicht so weit das man darüber DS-RECORDS einwerfen kann, der Weg per E-Mail funktioniert aber in der Regel binnen Minuten / Stunden.

Es kommt ja eher selten bis nie vor, das ich hier Werbung für ein Unternehmen mache, dieses hat es aber verdient.

So long…

Webseite: http://www.speedpartner.de/

E-Mail Adresse: info@speedpartner.de

Postfix SSL/TLS gesichert mit TLSA / DANE und DNSSEC

Mein Domains sind nun schon seit langem per DNSSEC gesichert. Schnell habe ich auch TLSA-RECORDS für mein SSL/TLS X.509 Zertifikat des Webservers Apache veröffentlicht, damit die verschlüsselte Verbindung zu meiner Webseite ebenfalls per DANE gesichert ist.

DNSSEC: https://www.kernel-error.de/dnssec

DANE: https://www.kernel-error.de/dnssec/tls-ssl-zertifikatschecksummen-im-dns

Seit Januar diesen Jahres beherscht nun Postfix ebenfalls die Möglichkeit TLSA Records zu prüfen. Da mache ich natürlich mit!

Zuerst muss die Postfix Version natürlich passen. Kleiner 2.11 sollte es nicht sein, die Postfixversion zeigt sich schnell per:

$ postconf -d | grep mail_version
mail_version = 2.11.0

Mein Mailserver bietet natürlich schon immer die Möglichkeit einer verschlüsselten Verbindung an. Daher gehe ich einfach mal nicht näher darauf ein, wie man sein Postfix dazu überredet. Ganz kurz… Aktivieren lässt sich die Unterstützung für DANE / TLSA mit folgenden drei Konfigurationsänderungen:

$ postconf -e "smtpd_use_tls = yes"
$ postconf -e "smtp_dns_support_level = dnssec"
$ postconf -e "smtp_tls_security_level = dane"

Keine Sorge, alles bietet einen Failback an, so leidet die Kommunikation mit _nicht_ DANE fähigen Systemen nicht.

Zum erstellen des TLSA-RECORDS muss selbstverständlich nicht unbedingt der von mir in früheren Beiträgen erwähnte Hash-slinger eingesetzt werden. Openssl macht dieses fast genau so schnell.

$ openssl x509 -in postfix.pem -outform DER | openssl sha256
(stdin)= 94c8e1bdfff4f6d3fec0c4e2f26293d78870650bfd3534e77b93cdaccb77eb95

Aus diesem Hash erstelle ich nun den TLSA RECORD. Für die E-Mail Kommunikation ist es mir lieb, wenn der TTL (Lebensdauer) des Records nicht ZU lange ist. Bei einem Zertifikatswechsel dauert es sonst unnötig lange bis der neue Record gültig ist. Daher setzte ich ihn auf 1 Stunde.

_25._tcp.smtp.kernel-error.de. 1H IN TLSA 3 1 1 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1
_465._tcp.smtp.kernel-error.de. 1H IN TLSA 3 1 1 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1

Wie zu sehen ist biete ich den TLSA RECORD direkt für Port TCP 25 und TCP 465 an. Schnell nur noch testen ob der TLSA RECORD mit dig auch sauber abgefragt werden kann.

$ dig _25._tcp.smtp.kernel-error.de +dnssec +m

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> _25._tcp.smtp.kernel-error.de +dnssec +m
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28381
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;_25._tcp.smtp.kernel-error.de. IN A

;; AUTHORITY SECTION:
kernel-error.de.        86400 IN SOA ns1.kernel-error.de. root.kernel-error.de. (
                                20140102708 ; serial
                                10000      ; refresh (2 hours 46 minutes 40 seconds)
                                1800       ; retry (30 minutes)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                                )
kernel-error.de.        86400 IN RRSIG SOA 7 2 86400 20150511054702 (
                                20140516054702 38150 kernel-error.de.
                                QXUpVl3myVAUGn/ox8J5aihAySHdWpojyPuhV5QKgDUy
                                qYRPyryWyBoGG+x5cGs0JpPBqQA3lRovAM4JFvC3hRmO
                                FU3fVTiYlvAJK7WsTSgPJLYpXrBnS+NN0O2UW3W+Ru1K
                                2P5dj+BWNO1wqXs+VU7WpMPwq/ESlK88hxXE1Gc= )
_25._tcp.smtp.kernel-error.de. 86400 IN NSEC _465._tcp.smtp.kernel-error.de. RRSIG NSEC TLSA
_25._tcp.smtp.kernel-error.de. 86400 IN RRSIG NSEC 7 5 86400 20150511054702 (
                                20140516054702 38150 kernel-error.de.
                                ToC8GtXFenieGjA32eoHACNGCg+tFr05vz6w9yiHYrDj
                                rHGBabc7MMjqUWNsf7L059YhR7dLoAPqhy2ZThWqFbRD
                                ZsfPQSgHIazEuKvOE7i2Ee/znU2d57X8nVkp8scUKZ1R
                                kGdK5DUDlAcYn0YdpjYaUTn2STdbM9IDcdrASPE= )

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mo Jan 27 08:50:36 2014
;; MSG SIZE  rcvd: 506

Schon lässt sich im Postfix Logfile erkennen ob Verbindungen getraut wird oder nicht.

Jan 27 08:32:02 mailserver postfix/smtp[3779]: Verified TLS connection established to mx02.example.de[99.88.12.167]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Jan 27 08:33:19 mailserver postfix/smtp[3779]: Untrusted TLS connection established to smtp2.example.de[2001:333:6661:99::34]:25: TLSv1 with cipher ADH-AES256-SHA (256/256 bits)

Wenn man mich fragt, ist die Kombination aus DNSSEC, DANE / TLSA deutlich besser als dieses hässliche EmiG. EmiG benötigt eine unnötig teure Zertifizierung durch den TüV, dieses kann sich nicht jeder leisten. Damit ist dieses „sichere“ Verfahren fast nur durch Unternehmen zu realisieren die genug Kohle haben. Kleinere werden damit einfach abgehängt. Verfahren die Sicherheit nur für „reiche“ zur Verfüfung stellen sollte man aus meiner Überzeugnung nicht unterstützen.

Eine weitere schnelle und einfache Möglichkeit seinen TLSA-RECORD des Mailservers / Postfix zu testen ist posttls-finger:

$ posttls-finger -t30 -T180 -c -L verbose,summary kernel-error.de
posttls-finger: initializing the client-side TLS engine                                                                                                                                                                          
posttls-finger: using DANE RR: _25._tcp.smtp.kernel-error.de IN TLSA 1 0 1 94:C8:E1:BD:FF:F4:F6:D3:FE:C0:C4:E2:F2:62:93:D7:88:70:65:0B:FD:35:34:E7:7B:93:CD:AC:CB:77:EB:95                                                       
posttls-finger: setting up TLS connection to smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25                                                                                                                                  
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: TLS cipher list "aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL"                                                                                        
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA                      
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA                      
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=0 verify=1 subject=/description=y0xkuso3gx7t8h0o/C=DE/ST=Nordrhein-Westfalen/L=Sprockh\xF6vel/O=Sebastian Van De Meer/CN=smtp.kernel-error.de/emailAddress=postmaster@kernel-error.de                                                                                                                                                                                                   
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=0 matched end entity certificate sha256 digest 94:C8:E1:BD:FF:F4:F6:D3:FE:C0:C4:E2:F2:62:93:D7:88:70:65:0B:FD:35:34:E7:7B:93:CD:AC:CB:77:EB:95         
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: subject_CN=smtp.kernel-error.de, issuer_CN=StartCom Class 2 Primary Intermediate Server CA, fingerprint=E1:92:93:D4:CA:E9:5D:44:B5:CC:A4:15:1F:12:A6:E0:B5:C2:97:56, pkey_fingerprint=E9:84:8E:51:47:99:90:53:0B:2C:2E:1E:70:6E:DE:CA:A4:65:8A:C5                                                                                                                                             
posttls-finger: Verified TLS connection established to smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

So bei Fragen, einfach fragen 🙂


09-08-2014 Update

Ich habe zur Auswertung den Mailgraph etwas angepasst ( mailgraph Graphen um DANE erweitern ). Dieser wirft mir nun den unten stehenden Graphen für ausgehende Verbindungen raus.

SPF Record kurz erklärt…

Ich bin in der letzten Zeit immer mal wieder zu meinem SPF Record Beispiel gefragt worden. Ihr wisst schon… Diese beiden:

kernel-error.de.    IN  TXT "v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 ptr:smtp.kernel-error.de mx a:smtp.kernel-error.de -all"
kernel-error.de.    IN  SPF "v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 ptr:smtp.kernel-error.de mx a:smtp.kernel-error.de -all"

Ich versuche das ganze noch einmal etwas aufzuschlüsseln. Die genannten Beispiele sollen die Möglichkeiten zeigen, welche man hat um den SPF-RECORD zu erstellen. Der echte SPF-RECORD sollte aber so schlank wie irgendwie möglich sein. Denn er wird ja theoretisch bei jeder eingehenden E-Mail geprüft. Um so länger er ist und umso mehr geprüft werden muss umso mehr DNS Lookups müssen gemacht werden. Man hat nach RFC nur maximal 10 DNS Abfragen, eine davon hat man schon verbrannt um den eigentlichen SPF RECORD zu holen. Es bleiben also noch 9 🙂 Kommt man über diese 10 Abfragen stirbt alles mit der Meldung:
Results – PermError SPF Permanent Error: Too many DNS lookups

Ist auch OK so, denn wenn der empfangende Mailserver für jede eingehende E-Mail hunderte DNS lookups durchführen muss, tut er ja nichts anders mehr!

Gut, nun zu meinem Beispielrecord.

v=spf1 ==> Ist die Protokollversion
ip4:212.23.142.146 ==> Von dieser IPv4 Adressen dürfen E-Mails kommen.
ip6:2001:7d8:8001:100::2 ==> Von dieser IPv6 Adresse dürfen E-Mails kommen.
ptr:smtp.kernel-error.de ==> Es dürfen E-Mails von den PTR Adresse“n“ des Hosts smtp.kernel-error.de kommen.
mx ==> Es dürfen E-Mails vom MX (Mail Exchange) der Domäne kernel-error.de kommen.
a:smtp.kernel-error.de ==> Es dürfen E-Mails von den IPv4 / IPv6 Adressen des Hosts smtp.kernel-error.de kommen.
==> Kommt die E-Mail von einem -nicht zutreffenden- System gilt der SPF-Test immer als Fehlschlag
all ==> Das ganze passiert immer.

Bei den IP-Adressen kann ebenfalls ein ganzes Netz angegeben werden. Zum Beispiel: 212.23.142.146/24

Beim mx könnte eine andere Domäne oder Subdomäne stehen. Zum Beispiel: mx:smtp.kernel-error.de damit dürften dann E-Mails vom MX der Domäne smtp.kernel-error.de kommen. Natürlich muss es diesen MX auch geben!!! Es geht noch mehr… Zum Beispiel habe ich in einer weiteren Domain von mir nur folgendes stehen:
v=spf1 include:kernel-error.de -all

include:kernel-error.de ==> Gibt an das bitte der SPF RECORD von der Domain kernel-error.de abgefragt und angewandt werden soll. Damit gilt die SPF-Policy der Domain kernel-error.de. Ich muss also nur eine Policy pflegen und lasse alle anderen Domains nur auf diese verweisen 🙂

Die Abfrage würde dann so aussehen:

DNS record(s):
    vandemeer.de. 86400 IN SPF "v=spf1 include:kernel-error.de -all"
    kernel-error.de. 86400 IN SPF "v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 -all"

Würde man nun den oben stehenden RECORD in die Zone kernel-error.de. werfen und ihn aktiv nutzen; Dann wird er funktionieren und absolut gültig sein. Das empfangende E-Mail System wird aber eine ganz Hand voll DNS Abfragen machen müssen um diese SPF Policy zu prüfen. Jetzt beantwortet sich sicher die Frage, warum ich einen anderen SPF-RECORD einsetzte als hier aufgeführt 😀 Denn die aufgeführten RECORDS sind schlicht ein Beispiel und keine Copy & Paste Vorlagen. Ok ok… Ich hätte das direkt genauer beschreiben sollen, hm?

Weniger ist im SPF RECORD also mehr. Man darf sich also überlegen welcher RECORD für seine Domain und sein System gerade der beste ist. Wenn es wechselnde IP Adresse gibt ist sicher ein A/AAAA RECORD besser, wenn sich dieser oft ändert dann ggf. ein MX der Domain oder ein ganzes Netz oder oder…

Mehr zum Lesen:

SPF
SPF-RECORD
SPF-RECORD erkärt

DMARC (Domain-based Message Authentication, Reporting & Conformance)

Habt ihr eigentlich schon etwas von DMARC (Domain-based Message Authentication, Reporting & Conformance) gehört? Nein… Dann dann haben wir das ja nun aufgeholt 😛

Im Grunde „erweitert“ DMARC die beiden Systeme SPF (Sender Policy Framework) und DKIM (DomainKeys Identified Mail). Warum und wie?!? Nun ja, beide Techniken sind erstmal ~nicht schlecht~. Setzt man sie ausgehend ein, fehlen dem Admin denn noch etwas die „Rückmeldungen“. OK, wenn etwas schief geht, jammern die User. Setzt man sie eingehend ein, würde es hin und wieder helfen wenn der „Absender“ einem etwas genauer sagen würde wie denn nun mit seinen Nachrichten umgegangen werden soll.

Hier springt nun DMAC -in die Bresche- (woher kommt eigentlich diese Redensart?). DMARC wird, wie bei SPF oder DKMI möglich, einfach als TXT-RECORD in der DNS Zone versenkt. Dort finden sich nun Informationen für den empfangenden Mailserver. Zum Beispiel kann angegeben werden wie viel Prozent der eingehenden E-Mails überhaupt gefiltert werden soll (pct), wie hart bei Fehlern im SPF (aspf) und DKIM (adkim) umgegangen werden soll, wie mit E-Mails der Haupt- (p) oder Subdomänen (sp) umgegangen werden soll und was tierisch geil für den Admin des Absendenden E-Mail Systems ist…. An welche E-Mail Adresse ein forensischer (das Wort trifft es, ich finde es aber doof :-P) Bericht (ruf) und wohin eine tägliche Zusammenfassung (rua) gesendet werden soll.

Diese Berichte schlagen normalerweise als E-Mail mit einem komprimierten ZIP-File im Gebäck auf. In diesem ZIP-File steckt dann ein XML-File (*würk* XML.. für die Auswertung denn noch geil). Diese kann man nun auswerten. So kann der Admin des absendenden E-Mail Systems sehen wie gut oder schlecht seine Bemühungen greifen. Er wird schnell über Probleme informiert und kann erkennen ob und wie stark seine Domain gerade -missbraucht- wird.

Eine E-Mail mit ZIP-File lässt sich sehr einfach automatisch auspacken und die XML Datei wird dann von irgendeinem Stück Software gefressen. Heraus kommt ein täglicher Bericht für den Admin. Ok, man könnte es schön bunt machen, dann kann man es auch einer Krawatte zum klicken geben 🙂

Klar muss der Empfänger es unterstützen, sonst bringt das alles nix. Aber jeder Absender, der bereits SPF und DKIM einsetzt, kann seinen DMARC Record schon mal erstellen, hm?

Ich probiere eine kurze Erklärung des DMARC TXT RECORDS an meinem…

_dmarc.kernel-error.de  IN TXT  "v=DMARC1; pct=100; rua=mailto:postmaster@kernel-error.de; ruf=mailto:postmaster@kernel-error.de; adkim=s; aspf=s; p=quarantine; sp=quarantine"

_dmarc. ==> ist halt der „Bezeichner“
kernel-error.de ==> japp die Domain
IN TXT ==> Internet und Text
„“ ==> Dazwischen ist der Text
; ==> Trennt die Optionen
v=DMARC1 ==> Protokollversion, hier also 1
pct=100 ==> 100% meiner vermeintlichen Nachrichten sollen gefiltert werden
rua=mailto:postmaster@kernel-error.de ==> Zusammenfassung geht an postmaster@kernel-error.de
ruf=… ==> der forensiche Bericht geht ebenfalls an den Postmaster
adkim=s ==> DKIM soll nicht relaxed (r) sondern strict (s) ausgewertet werden
aspf=s ==> auch strict
p=quarantine ==> Fehlgeschlagenes der Hauptdomäne sollen als SPAM markiert werden.
sp=quarantine ==> bei der Subdomäne auch.

Noch eine Kleinigkeit. Wenn man mehrere Domains betreut und die Berichte an eine zentrale E-Mail Adresse senden möchte dann muss man noch etwas beachten. Denn sollen die Berichte an eine E-Mail Adresse außerhalb der Domain des DMARC RECORDS gesendet werden, dann muss dieses in der Empfängerdomäne „erlaubt“ werden. Dieses geht über einen gesonderten TXT RECORD.

kernel-error.com._report._dmarc.kernel-error.de TXT "v=DMARC1"

Wenn man diesen RECORD als Beispiel nimmt, würde er in der Zone kernel-error.DE stehen. Damit würden die Berichte aus der Zone kernel-error.COM an die Adresse xyz@kernel-error.de zugestellt werden können.

Noch Fragen? Na dann fragen 😀


UPDATE 12.12.2013

Ok ok… da die Frage jetzt ein paar mal aufgekommen ist, wie ein solcher Report aussieht…. Hier ein Beispiel: >> klick <<

Zur besseren Ansicht kann ich auch hier nur wieder auf dmarcian.com verlinken. Hier gibt es einen XML du Human Konverter 🙂 

Frage beantwortet?

DNSSEC und DNS-based Authentication of Named Entities (DANE)

Schon einige Zeit ist meine Domain per DNSSEC geschützt und der Zugriff ist ebenfalls per SSL/TLS möglich. Mit DANE (DNS-based Authentication of Named Entities) ist es jetzt möglich die eingesetzten X.509 Zertifikate bzw. deren Checksummen mit dem DNS „abzugleichen“.

Die Idee dahinter ist, das löchrige System der CAs (certificate authority oder certification authority) etwas sicherer zu machen / zu ersetzten.

Unterstützt ein Client, wie zum Beispiel ein Browser, DANE so kann er beim verschlüsselten Verbindungsaufbau mit einem Server (z.B.: Webserver). Prüfen ob die Checksumme des TLS Zertifikates mit der in der DNS Zone hinterlegten übereinstimmt. So kann man diesem Zertifikat „trauen“, selbst wenn es sich um ein selbst signiertes Zertifikat handelt oder das Root-Zertifikat der CA nicht in seinem Client enthalten ist.

Selbstverständlich wird damit nicht sichergestellt das die angegebene Person oder Organisation wirklich hinter dem Zertifikat steht. Hier hängt es dann wieder an der CA, der muss man zum einen selbst vertrauen und zum anderen sollte sie dafür sorgen dass niemand an ihre Zertifikate kommt. Nichts ist 100%tig sicher! Man kann nur versuchen dem absoluten Vertrauen so nahe wie möglich zu kommen. Daher ist es sehr angenehem wenn verschiedene Mechanismen ineinandergreifen und sich nach Möglichkeit auch gegenseitig prüfen.

Dabei sollte der Benutzer aber mit so wenig technischen Dingen gequält werden wie nur möglich. DNSSEC, DANE und TLS ist aus meiner Sicht im Moment eine recht gute Kombination. Wenn alles sauber im Client implementiert ist und die Admins ihre Arbeit gemacht haben, bekommt der Benutzer nur die Information: „Was du da gerade machst ist möglicherweise nicht der Server mit dem du sprechen wolltest. Lass es lieber!“

Klar steht und fällt am Ende alles mit dem Benutzer. Hier müssen die Benutzer geschult und aufgeklährt werden. Den technischen Hintergrund muss aber kein Anwender verstehen. 

Ich stehe ja auf so etwas. Daher habe ich es direkt bei mir implementiert.

Bind kann ab der Version 9.8.3 mit TLSA RECORDS umgehen:

#### SCHNIPP ####
Feature Changes

* BIND now recognizes the TLSA resource record type, created to
support IETF DANE (DNS-based Authentication of Named Entities)
[RT #28989]
#### SCHNAPP ####

Damit es einfacher wird bietet die Internet Society (http://www.internetsociety.org/deploy360/resources/hashslinger-a-tool-for-creating-tlsa-records-for-dane/) ein Tool mit dem Namen Hash-slinger an. Dieses Tool unterstützt beim erstellen der TLSA-RECORDS und natürlich bei der Prüfung der DNS-RECORDS.

Für meine Hauptdomain findet sich folgender RECORD in der Zone:

_443._tcp.www.kernel-error.de. IN TLSA 3 0 1 a3218154fbaa792afba91075ea36b5ea6623d46766a10ff1d06e7de461f933f7

Geprüft wird dieser korrekt wie folgt, einmal für die IPv4 und einmal für die IPv6 Adresse:

$ ./tlsa -d -v www.kernel-error.de
Received the following record for name _443._tcp.www.kernel-error.de.:
Usage: 3 (End-Entity)
Selector: 0 (Certificate)
Matching Type: 1 (SHA-256)
Certificate for Association: a3218154fbaa792afba91075ea36b5ea6623d46766a10ff1d06e7de461f933f7
This record is valid (well-formed).
Attempting to verify the record with the TLS service...
Got the following IP: 212.23.142.146
SUCCESS (usage 3): The certificate offered by the server matches the TLSA record
The matched certificate has Subject: /description=3G0bqBiLJsg0y2nv/C=DE/ST=Nordrhein-Westfalen/L=Sprockh\xF6vel/O=Sebastian Van De Meer/CN=www.kernel-error.de/emailAddress=postmaster@kernel-error.de
Got the following IP: 2001:7d8:8001:100::dead:beef
SUCCESS (usage 3): The certificate offered by the server matches the TLSA record
The matched certificate has Subject: /description=3G0bqBiLJsg0y2nv/C=DE/ST=Nordrhein-Westfalen/L=Sprockh\xF6vel/O=Sebastian Van De Meer/CN=www.kernel-error.de/emailAddress=postmaster@kernel-error.de

Die gängigen Browser lassen sich bereits mit Plugins nachrüsten.

Spannende Infos zum Thema DANE gibt es hier:
http://www.internetsociety.org/articles/dane-taking-tls-authentication-next-level-using-dnssec

Wer nur schnell und einfach die TLSA Records testen möchte, kann dieses hier tun: http://check.sidnlabs.nl/dane/


U-P-D-A-T-E 28.01.2014

Wie sich das Thema zusammen mit Postfix nutzen lässt um auch etwas gegen dieses hässliche EmiG (E-Mail made in Germany) zu tun ist hier zu finden: https://www.kernel-error.de/kernel-error-blog/260-postfix-ssl-tls-gesichert-mit-tlsa-dane-und-dnssec


U-P-D-A-T-E 09.08.2014

Ich habe den Mailgraph erweitert ( mailgraph Graphen um DANE erweitern ), damit er mir den unten stehenden Graphen erzeugt.

« Ältere Beiträge Neuere Beiträge »

© 2024 -=Kernel-Error=-

Theme von Anders NorénHoch ↑