Datenhaufen zu IT und Elektronik.

Kategorie: IT-Security (Seite 10 von 15)

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

Openfire unsichere Cipher und Protokolle deaktivieren

Der Jabber/XMPP Server von Ignite Realtime, Openfire ist ein ganz nettes System. Leider ist das Thema Sicherheit noch nicht ganz in der aktuellen Version angekommen. Bei den Entwicklern schon. In den aktuellen Nightly Builds sind bereits die „unsichern“ Protokolle und cipher im Default aus. In der Beta geht es so… Die aktuelle stable Openfire Version 3.9.3 bietet leider weder etwas einstellbares, noch eine zufriedenstellende standard Konfiguration.

Sucht man nun im Internet nach: „how to disable weak ciphers“ in Verbindung mit Openfire findet man derzeit nur viele Menschen, welche auf der Suche nach einer gangbaren Lösung sind. Leider finden sich kaum welche 🙁

Eine Lösung möchte ich hier kurz vorstellen….

Openfire basiert auf Java. Ab Oracle Java 8 gibt es eines hier Möglichkeiten die Protokolle und Cipher zu deaktivieren, welche nicht genutzt werden sollen.

Wenn ich also von einem Debian oder Ubuntu System ausgehe und ich hinsichtlich Java nur über Openfire nachdenken muss, lässt sich mit folgender Konfiguration von Oracle Java 8 ein brauchbares Ergebnis erzielen.

In der Konfigurationsdatei: /usr/lib/jvm/java-8-oracle/jre/lib/security/java.security sollten folgende zwei Optionen gesetzte werden. Dabei ist natürlich darauf zu achten, dass sie nicht noch einmal in der Konfiguration vorkommen 😉

# Example:
#   jdk.certpath.disabledAlgorithms=MD2, DSA, RSA keySize < 2048
#
#
jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024
# Example:
#   jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048
jdk.tls.disabledAlgorithms=SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA, SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, SSL_DH_anon_WITH_3DES_EDE_CBC_SHA, SSL_DH_anon_WITH_DES_CBC_SHA, SSL_DH_anon_WITH_RC4_128_MD5, SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA, SSL_DH_DSS_WITH_DES_CBC_SHA, SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DH_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA, SSL_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_RC4_128_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_FORTEZZA_DMS_WITH_FORTEZZA_CBC_SHA, SSL_FORTEZZA_DMS_WITH_NULL_SHA, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA, SSL_RSA_EXPORT1024_WITH_RC4_56_SHA, SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_FIPS_WITH_DES_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_RSA_WITH_IDEA_CBC_SHA, SSL_RSA_WITH_NULL_MD5, SSL_RSA_WITH_NULL_SHA, SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, SSL_DH_anon_WITH_RC4_128_MD5, SSL_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA, SSL_DHE_DSS_WITH_RC4_128_SHA, TLS_DHE_PSK_WITH_RC4_128_SHA, TLS_ECDH_anon_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_PSK_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_KRB5_EXPORT_WITH_RC4_40_MD5, TLS_KRB5_EXPORT_WITH_RC4_40_SHA, TLS_KRB5_WITH_RC4_128_MD5, TLS_KRB5_WITH_RC4_128_SHA, TLS_PSK_WITH_RC4_128_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT1024_WITH_RC4_56_SHA, TLS_RSA_PSK_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSLv3

Damit wird SSLv3 deaktiviert, MD5 sowie RC4 werden ebenso wie einige recht schlechte Cipher nicht weiter verwendet. Mehr Informationen erhält man über die Schlagwörter: Java8 Algorithm restrictions for Secure Socket Layer/Transport Layer Security processing sowie Java8 Algorithm restrictions for certification path processing

Ein Starten und Stoppen des Openfire sollte diese Einstellungen nun aktivieren. In diesem Zusammenhang sollte natürlich noch auf die JCE Unlimited Strength Jurisdiction Policy Files geachtet werden. Diese ermöglichen höhere Bit-Stärken als 128!

>>Openfire AES 256 und JCE Unlimited Strength Jurisdiction Policy Files<<

Damit lassen sich nun mit dem IM Observatory für Client und Server folgende Ergebnise / Reports erzielen:

IM Observatory client report for jabber.kernel-error.de
https://xmpp.net/result.php?id=115781

IM Observatory server report for jabber.kernel-error.de
https://xmpp.net/result.php?id=115782

Noch Fragen?

Mal wieder auffällig viele Brute-Force SSH Angriffe….

Seit gestern fällt es irgendwie auf… Da rattert wieder etwas über die Systeme 😀

Probiert werden die User:

– root
– admin
– mail
– Alphanetworks
– MANAGER
– test
– Factory
– vodafone
– telecomadmin
– draytek
– super
– FIELD
– ADVMAIL
– WP
– HELLO
– citel
– SPOOLMAN
– comcast
– wlseuser
– OPERATOR
– PCUSER
– MGR
– patrol
– netadmin
– anonymous
– craft
– websecadm
– netman
– MD110
– supervisor
– tiger
– manuf
– PBX
– NETWORK
– MDaemon
– readonly
– davox
– scout
– blank
– coress
– usw. usw. usw…..

Spannenderweise mit immer neuen Adressen aus verschiedenen großen Netzen. Im groben lässt es sich „eindampfen“ auf:

– 117.253.0.0/16
– 109.161.236.0/22
– 189.51.16.0/20

Hier und da noch etwas verteiltes… Indien, Brasilien, Italien, wenn man dem WHOIS trauen kann 😛 Was da wieder los ist? Dann wird wohl bald wieder mehr Spam kommen, hm?

Ich wünsche in jedem Fall ein paar klebrige Finger!

Jan 11 11:42:53 ssh-honeypot sshd[21822]: Invalid user MANAGER from 182.74.23.34
Jan 11 11:42:53 ssh-honeypot sshd[21822]: input_userauth_request: invalid user MANAGER [preauth]
Jan 11 11:42:56 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:42:58 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:01 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:03 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:05 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:08 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2

Jabber – 404 remote server not found – Openfire

Nachdem ich nun für die S2S-Verbindungen TLS erzwinge, sind ein paar Openfire User zu mir gekommen und beklagen sich darüber, dass ihre User im Client ein: „404 remote server not found“ bekommen.

Verbindungen/Nachrichten in die eine Richtung gehen durch und wenn die Unterhaltung einmal gestartet ist, „klappt“ es dann auch für eine gewisse Zeit. Ich muss zugeben, ein etwas spannender Effekt, welchen einen nicht direkt auf die Lösung des Problem bringt. Das Problem liegt nicht an meinem Jabber Server und nicht an meinen DNS Einstellungen. Es hängt tatsächlich am Openfire auf der Gegenseite. Java 6 fehlt im Keystore das Intermediate Zertifikat von StartSSL. Mein Server sendet es zwar mit, denn noch bekommt es Java 6 und einige Versionen 7 wohl nicht hin, die Kette korrekt zu bauen. Im Openfire warn.log finden sich dann Meldungen wie:

warn.log.1:2014.11.18 08:00:48 org.jivesoftware.openfire.server.ServerDialback - Error verifying key of remote server: jabber.kernel-error.de
warn.log.1:2014.11.18 08:00:48 org.jivesoftware.openfire.server.ServerDialback - ServerDialback: OS - Ignoring unexpected answer in validation from: kernel-error.de id: 1234567890 for domain: JABBERDOMAIN answer:<stream:features xmlns:stream="http://etherx.jabber.org/streams"><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls></stream:features>

Erschlagen lässt sich dieses Problem, indem der Admin des Openfire-Systems einfach das Intermediate Zertifikat der CA in seinen Keystore packt. Wie? so…

Zuerst in den default Ordner des Openfire auf einem Debian System wandern und dann den Openfire zur Sicherheit beenden:

$ cd /etc/openfire/security/
$ /etc/init.d/openfire stop

Jetzt das Zertifikat von der Webseite der CA herunterladen und es importieren:

$ wget "http://www.startssl.com/certs/sub.class2.server.ca.crt"
$ keytool -import -keystore truststore -alias startcom.ca.sub2 -file sub.class2.server.ca.crt
Enter keystore password:  
Certificate was added to keystore

Default Kennwort ist: changeit

Wenn man schon dabei ist, kann man (sofern gewünscht) auch direkt die Zertifikate von CAcert.org importieren. Viele Systeme nutzen diese:

$ wget "http://www.cacert.org/certs/root.crt"
$ keytool -import -keystore truststore -alias CAcert.root.ca -file root.crt
Enter keystore password:  
Certificate already exists in keystore under alias <CAcert.root.ca>
Do you still want to add it? [no]:  no
Certificate was not added to keystore

$ wget "http://www.cacert.org/certs/class3.crt"
$ keytool -import -keystore truststore -alias CAcert.Class3.sub.ca -file class3.crt
Enter keystore password:  
Certificate was added to keystore

Ist eines der Zertifikate bereits vorhanden, macht es natürlich keinen Sinn dieses zu überschreiben, sofern es kein Problem mit diesem gibt.
Als letzten Schritt einfach Openfire wieder starten.

$ /etc/init.d/openfire start

Ab jetzt sollte es dann zu keinen hässlichen Logmeldungen mehr führen und alle können wieder schreiben 🙂

So long….


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

Da die Frage inzwischen schon vier mal bei mir angekommen ist… Wie testet man denn ob das Intermidiate Zertifikate überhaupt korrekt mit übergeben wird? Ganz einfach mit openssl 🙂

Spannend ist hier die Zeile: Verify return code: 0 (ok)

Steht hier etwas anderes, gibt es ein Problem.

$ openssl s_client -showcerts -connect jabber.kernel-error.de:5222 -starttls xmpp
CONNECTED(00000003)
depth=2 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Certification Authority
verify return:1
depth=1 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Class 2 Primary Intermediate Server CA
verify return:1
depth=0 description = pViXGk1aRdP23kII, C = DE, ST = Nordrhein-Westfalen, L = Hattingen, O = Sebastian Van De Meer, CN = jabber.kernel-error.de, emailAddress = postmaster@kernel-error.de
verify return:1
---
Certificate chain
 0 s:/description=pViXGk1aRdP23kII/C=DE/ST=Nordrhein-Westfalen/L=Hattingen/O=Sebastian Van De Meer/CN=jabber.kernel-error.de/emailAddress=postmaster@kernel-error.de
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA
-----BEGIN CERTIFICATE-----
MIIG4zCCBcugAwIBAgIDAjIFMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJ
TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0
YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg
MiBQcmltYXJ5IEludGVybWVkaWF0ZSBTZXJ2ZXIgQ0EwHhcNMTQwNTE4MTU0NTU2
WhcNMTYwNTE4MTgwOTMwWjCBxjEZMBcGA1UEDRMQcFZpWEdrMWFSZFAyM2tJSTEL
MAkGA1UEBhMCREUxHDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xEjAQBgNV
BAcTCUhhdHRpbmdlbjEeMBwGA1UEChMVU2ViYXN0aWFuIFZhbiBEZSBNZWVyMR8w
HQYDVQQDExZqYWJiZXIua2VybmVsLWVycm9yLmRlMSkwJwYJKoZIhvcNAQkBFhpw
b3N0bWFzdGVyQGtlcm5lbC1lcnJvci5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAKJmXUJxwqipigjZf5cdLCMLcyThMO0Jtl7liZbh5Mxklho/NONN
PFdOT4thBG63SDol7XJm3ke1MJLZJeaaYXXXUo5aEQ8U1DGImSerfs8cexLFAczo
qc8c6Jm5x2wXhDIxpU7zaL9duX1gaJ8mbNiX+xoNUdx9QIENlXz/xdtVu0l95McK
Esrk3OZ11wyF1GSnFJtAQNC9Bn7fPV4kArZdh/OV+0tTUpM+EMG8PR2iQg6uVvhN
TNwzRKrxTVClmBRLyeT10Nhjt3rkB+bhGCWbXVtwitS3mlMEL7QoNPj7iRbIOUfF
TheJJ3x3PjxfmAubpfo/ndsGjV2c/jw2OmMCAwEAAaOCAxAwggMMMAkGA1UdEwQC
MAAwCwYDVR0PBAQDAgOoMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATAd
BgNVHQ4EFgQU/3ZeNF1M/zhTpWBrad0YI7q3BGAwHwYDVR0jBBgwFoAUEdsjRf1U
zGpxb4SKA9e+9wEvJoYwTAYDVR0RBEUwQ4IWamFiYmVyLmtlcm5lbC1lcnJvci5k
ZYIPa2VybmVsLWVycm9yLmRlghgqLmphYmJlci5rZXJuZWwtZXJyb3IuZGUwggFW
BgNVHSAEggFNMIIBSTAIBgZngQwBAgIwggE7BgsrBgEEAYG1NwECAzCCASowLgYI
KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcG
CCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5
MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRv
IHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw
dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdh
dGlvbnMuMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9jcmwuc3RhcnRzc2wuY29t
L2NydDItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0
cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvc2VydmVyL2NhMEIGCCsG
AQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3My
LnNlcnZlci5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vMA0GCSqGSIb3DQEBBQUAA4IBAQBcMcSJxbr52s1gzaH7zjh0FfveuiTvPIZY
enV1UxoPZLeFMAIUsZf2h/hGTXDNhH48bcF8eRcbMnPhS8xQPEXSNd7yFtPnpE6c
3jdjE6+Fm3Rd6MZ8BIruB98T8cc74LK3NoWxdnJNLs3+D2W2lMUjpCUgggHSNoOt
d73lXFYSxbu7+lOIE/w0oQeYKD6/aGGgZFaUdM2B1OHEz2z9skhQgFJkM6aAFK03
sH4KaYnwdnyNpuS8XpPhmrQ6KMZBQMi43TcH3mQtgTUXjZOC7i8ZSLzAtg0mdqSy
CJqfAKS6X/7ARyMHNNlZWDWXRuScs2k7x58afIx60MTp50SFSB4F
-----END CERTIFICATE-----
 1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
-----BEGIN CERTIFICATE-----
MIIGNDCCBBygAwIBAgIBGjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEW
MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg
Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjA1NzA5WhcNMTcxMDI0MjA1NzA5WjCB
jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0
YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgU2VydmVyIENBMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4k85L6GMmoWtCA4IPlfyiAEh
G5SpbOK426oZGEY6UqH1D/RujOqWjJaHeRNAUS8i8gyLhw9l33F0NENVsTUJm9m8
H/rrQtCXQHK3Q5Y9upadXVACHJuRjZzArNe7LxfXyz6CnXPrB0KSss1ks3RVG7RL
hiEs93iHMuAW5Nq9TJXqpAp+tgoNLorPVavD5d1Bik7mb2VsskDPF125w2oLJxGE
d2H2wnztwI14FBiZgZl1Y7foU9O6YekO+qIw80aiuckfbIBaQKwn7UhHM7BUxkYa
8zVhwQIpkFR+ZE3EMFICgtffziFuGJHXuKuMJxe18KMBL47SLoc6PbQpZ4rEAwID
AQABo4IBrTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYD
VR0OBBYEFBHbI0X9VMxqcW+EigPXvvcBLyaGMB8GA1UdIwQYMBaAFE4L7xqkQFul
F2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDov
L29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0
c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0
BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRl
LnBkZjANBgkqhkiG9w0BAQUFAAOCAgEAnQfh7pB2MWcWRXCMy4SLS1doRKWJwfJ+
yyiL9edwd9W29AshYKWhdHMkIoDW2LqNomJdCTVCKfs5Y0ULpLA4Gmj0lRPM4EOU
7Os5GuxXKdmZbfWEzY5zrsncavqenRZkkwjHHMKJVJ53gJD2uSl26xNnSFn4Ljox
uMnTiOVfTtIZPUOO15L/zzi24VuKUx3OrLR2L9j3QGPV7mnzRX2gYsFhw3XtsntN
rCEnME5ZRmqTF8rIOS0Bc2Vb6UGbERecyMhK76F2YC2uk/8M1TMTn08Tzt2G8fz4
NVQVqFvnhX76Nwn/i7gxSZ4Nbt600hItuO3Iw/G2QqBMl3nf/sOjn6H0bSyEd6Si
BeEX/zHdmvO4esNSwhERt1Axin/M51qJzPeGmmGSTy+UtpjHeOBiS0N9PN7WmrQQ
oUCcSyrcuNDUnv3xhHgbDlePaVRCaHvqoO91DweijHOZq1X1BwnSrzgDapADDC+P
4uhDwjHpb62H5Y29TiyJS1HmnExUdsASgVOb7KD8LJzaGJVuHjgmQid4YAjff20y
6NjAbx/rJnWfk/x7G/41kNxTowemP4NVCitOYoIlzmYwXSzg+RkbdbmdmFamgyd6
0Y+NWZP8P3PXLrQsldiL98l+x/ydrHIEH9LMF/TtNGCbnkqXBP7dcg5XVFEGcE3v
qhykguAzx/Q=
-----END CERTIFICATE-----
---
Server certificate
subject=/description=pViXGk1aRdP23kII/C=DE/ST=Nordrhein-Westfalen/L=Hattingen/O=Sebastian Van De Meer/CN=jabber.kernel-error.de/emailAddress=postmaster@kernel-error.de
issuer=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA
---
No client certificate CA names sent
---
SSL handshake has read 4537 bytes and written 612 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 98D942E7D6BD132AE7E19F13AFBE5C0C7A2F4CA651B9679B98E200A841572ABE78BB43B5572C1929B2423EC61008BBDD
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1416399042
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
read:errno=0

DNSSEC: KSK auf 4096-Bit aktualisieren und SHA-512 vorbereiten​

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/

Alternative SPF-RECORDS im DNS

Da ich es gerade mal wieder auf dem Tisch habe…. Ja, „früher“ konnte man verschiedene RECORDS im DNS setzten um SPF-RECORDS zu veröffentlichen. So auch einen Record Type mit dem direkten Namen SPF. Seit 2014 ist dem aber nicht mehr so! Denn ab jetzt soll man seine SPF-Records nur noch als TXT-Record (RFC1035 Typ 16) veröffentlichen. Dieses steht im fertigen RFC7208 Abschnitt 3.1.

Damit also bitte die ganzen anderen RECORDS zu SPF aus dem DNS entfernen und nur noch TXT-RECORDS einsetzten. Ich freue mich darüber, denn bisher musste man sonst eine Vielzahl verschiedener Records pflegen, da man sich nicht sicher sein konnte, welchen jetzt bitte die Implementierung des Empfängers nutzt. Zugegeben, die Basis TXT war die am meisten verbreitete Version. Denn noch gab es da hin und wieder ein Problem 🙂 Nun steht das RFC bereits einige Zeit fest, und ich habe alle anderen „SPF-RECORDS“ aus dem DNS entfernt. Nun also nur noch TXT bei mir 😀

So long

Kein Jabber/XMPP mehr ohne Transportverschlüsselung

Hallo zusammen,

wie ja bereits vor einiger Zeit angekündigt, habe ich heute TLS als Transportverschlüsselung zwischen den Server to Server Verbindungen erzwungen. Für die Clients s2c besteht dieser Zwang bereits seit langem, nun also auch für die Verbindungen zwischen der Server.

Ich habe mir natürlich vorher die Mühe gemacht, andere Serverbetreiber anzuschreiben, wenn ich zu ihnen keine verschlüsselte s2s Verbindung aufbauen konnte. Ein paar sind aktiv geworden, ein paar nicht. Die Anzahl der nicht verschlüsselten s2s Verbindungen ist denn noch verschwindend gering! Ich habe diese Verbindungen also hiermit bewusst „abgehängt“.

Sollte ihr also aktuell Probleme mit der Verbindung zu oder von meinem System haben, bitte einfach melden!

So long…

SSLv3 ist tot…

Nein, ich habe es nicht überlesen 🙂 SSLv3 ist damit wohl hoffentlich tot!

Es ist ja nicht so als wenn man nicht schon davor gewarnt hätte 😛 Oh was hat diese Meldung bei mir für gute Laune geführt! Wieder mal ein richtiger „Told you so“ Moment für mich.

Oh ja, was zum Lesen gefällig?

http://googleonlinesecurity.blogspot.ru/2014/10/this-poodle-bites-exploiting-ssl-30.htmlhttps://www.openssl.org/~bodo/ssl-poodle.pdf

Bäääähhhhmmmm! Das schreit nach einem GIF!

Auf die schnell böse Dinge deaktivieren…

Postfix:

smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_ciphers=high
tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA

Dovecot:

ssl_cipher_list = 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:!CAMELLIA:!DES:!MD5:!PSK:!RC4
ssl_protocols = !SSLv2 !SSLv3

Apache2:

SSLEngine on
SSLProtocol +ALL -SSLv3 -SSLv2
SSLHonorCipherOrder On
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:!CAMELLIA:!DES:!MD5:!PSK:!RC4
SSLCompression off
Header always set Strict-Transport-Security "max-age=15552000"

Linux Backintime Datensicherung / Backup

Kaum schreibe ich etwas zur Datensicherung meines FreeBSD Notebooks, schon kommt die Frage, wie ich einen/meinen Linux Desktop sichern würde….

Um es kurz zu machen, ich nutze dazu seit langem bereits das Programm backintime. Es arbeitet mit rsync und hardlinks ebenfalls bietet es die Möglichkeit seine Sicherungen auf alle möglichen Ziele zu schieben, so auch per SSH nach irgendwo.

Wer rsnapshot für Unix Server kennt… Es ist so ähnlich nur bei Bedarf mit GUI. Zusätzlich lässt sich noch schnell und einfach etwas Krypto ins Spiel bringen. Die Datensicherungen lassen sich so sehr schnell und vor allem einfach erstellen und wiederherstellen. Probiert es einfach mal!

Fragen? Dann fragen 🙂

Die ersten Zertifikate mit SHA-256 Checksumme und SNI

Auf meiner privaten Kisten sind nun die ersten Zertifikate mit SHA256 Checksumme aktiv. Zum ersten mal auch auf einer IPv4 per SNI. Damit habe ich nun zwar alle Windows XP User an der Stelle abgehängt… 2014 kann ich damit aber mehr als gut leben 😀

Gewarnt hatte ich ja bereits und inzwischen geht Google hier ja auch nach vorne: Google Browser Chrome wirft SHA1 Zertifikate weg…

Damit ist nun mein munin (https://munin.kernel-error.com/) und der ampache (https://ampache.kernel-error.com) nur noch über diesen Weg und mit diesen Zertifikaten erreichbar \o/

https://www.ssllabs.com/ssltest/analyze.html?d=ampache.kernel-error.com

https://www.ssllabs.com/ssltest/analyze.html?d=munin.kernel-error.com

So long…

Google Browser Chrome wirft SHA1 Zertifikate weg…

Na wie geil ist das denn Bitte? Das SHA1 nicht der Brüller ist wissen wir ja inzwischen alle. Das man nicht (wie bei MD5) so lange warten sollte bis es nicht nur ein theoretisches Problem, sondern ein echtes gibt… Ja, das können sich viele denken. Leider bekommt man viel „Entscheider“ nicht so einfach davon überzeugt, denn es hängt meist viel Geld an so einer Entscheidung. Ggf. müssen ja Softwaremodule getauscht werden, Hardware könnte ersetzt werden müssen usw. usw.. Windows XP wird so zum Beispiel abgehängt!

Denn noch überrascht mich Google in der letzten Zeit immer mal wieder hinsichtlich irgendwelcher Sicherheitsgeschichten. So nun ebenfalls wieder mit der Ankündigung, dass sie SHA1 aus ihrem Browser haben wollen. Nutzt man also Zertifikate mit SHA1 Checksumme, gibt es bald eine Meldung im Browser. Diese Meldung wird dem Anwender vermitteln: „Diese Seite ist nicht ganz sicher!“. Direkt gefolgt von einer deutlichen roten Meldung bis hin zum Punkt dass solche Zertifikate nicht mehr unterstützt werden sollen. Dieses erst so ab ca. 2017… Wenn man aber nun über die durchschnittliche Gültigkeitsdauer von „Kaufzertifikaten“ (2 Jahre) ausgeht… Tja, dann kann man so gesehen zum letzten mal mit ~gutem Gewissen~ ein SHA1 Zertifikat am 31.12.2014 kaufen. OK, man kann natürlich zu jeder Zeit ein neues Zertifikat mit SHA256 Checksumme erstellen, dieses kostet dann aber auch wieder Geld. Man kann sich also jetzt überlegen ob man zwei mal Geld bezahlen möchte oder nicht!

http://googleonlinesecurity.blogspot.de/ 

Was mir an Google so gefällt, ist dass sie im Moment immer mal wieder „sanften“ Druck auf die Entscheider ausüben um doch etwas mehr Sicherheit ins Internet zu bringen. SHA1 ist Käse, als Checksumme im Zertifikat oder in den Ciphern, genau wie RC4, MD5 oder ähnliches. Kein Anwender wird dieses von sich aus prüfen und kein Anwender wird dieses von sich aus in Frage stellen. Beginnt die Anwendungssoftware zu moppern… Dann gibt es schnell eine gewissen „Nachfrage“ und somit Bewegung bei den Entscheidern oder den „weiter ==> weiter ==> fertigstellen Admins“.

Oh ja, Microsoft sowie Mozilla hegen sehr ähnliche Pläne! Ich habe das Thema ja schon einmal vor knapp einem Jahr aufgegriffen ( 27. September 2013). Sicheres SSL / TLS Zertifikat 
Meine Empfehlung ist also: „Testen ob ihr/eure Systeme mit SHA256 Zertifikaten umgehen können und vor den nächsten Kauf entscheiden, ob es wirklich noch mal ein SHA1 Zertifikat werden soll oder nicht..“!

Nur, wer hört schon auf mich? 😛


Na schau mal einer an…. Inzwischen „zucken“ sogar die großen CAs:

Wichtiger Servicehinweis
Sehr geehrte/r Sebastian van de Meer,

Sie haben vielleicht bereits gehört, dass Google beabsichtigt, die Unterstützung für SSL-Zertifikate mit dem Hash-Algorithmus SHA-1 einzustellen. Als erster Schritt ist geplant, die Vertrauenszeichen im Browser Chrome™ abzuschwächen und Warnmeldungen anzuzeigen, wenn eine Website mit einem solchen Zertifikat aufgerufen wird. Das wird voraussichtlich ab der Version 39 von Chrome geschehen, die für November 2014 geplant ist. Weitere Informationen sind in diesem Google-Blog erhältlich (auf Englisch). Symantec empfiehlt, dass Sie proaktiv die folgenden Maßnahmen ergreifen, um zu verhindern, dass Besucher diese abgeschwächten Vertrauensmarken oder Warnmeldungen sehen, wenn sie Ihre Website in Chrome 39 aufrufen:

1. Nutzen Sie die SSL Toolbox, um herauszufinden, welche Ihrer Zertifikate SHA-1 nutzen.
2. Ersetzen Sie Zertifikate mit SHA-1, die nach dem 31. Dezember 2015 ablaufen, kostenlos durch Zertifikate mit SHA-2. Weitere Informationen dazu finden Sie in Artikel SO7146 in unserer Knowledge Base (auf Englisch).

Hinweis: Root-Zertifikate mit SHA-1 sind nicht von dieser Änderung betroffen.

Weitere Informationen finden Sie unter:

• Symantec-Informationsseite zu SHA-1
• Symantec Community Forum: Website-Sicherheitslösungen (auf Englisch)
Falls Sie noch weitere Fragen haben, wenden Sie sich bitte unter der Adresse ssltechsupport_de@symantec.com an Ihr Support-Team oder setzen Sie sich mit Ihrem Account Manager in Verbindung.
Mit freundlichen Grüßen

Ihr Support-Team von
Symantec Website Security Solutions

##############################################################################################################################

Important Service Announcement
Dear Sebastian,

We would like to inform you of Google’s intent to phase out support for certificates using a SHA-1 hashing algorithm via degraded visual indicators and warnings in the Chrome™ browser. These changes are expected to take effect in the production version of Chrome version 39 in November 2014. You can find more information regarding the proposed plan on Google’s blog.

As a proactive measure, in order to help ensure that Chrome 39 users visiting your websites do not encounter any UI degraded indicators, Symantec recommends the following:
1. Identify certificates that have a SHA-1 algorithm using the Thawte Certificate Center or SSL Toolbox. For more information, please refer to Knowledge Center article SO26488.
2. Replace any SHA-1 certificates that expire beyond December 31, 2015 with SHA-2 certificates at no additional cost. For more information, please refer to Knowledge Center article SO13487.

Please note that SHA-1 root certificates will not be affected by the plan.

Here are some additional resources for your reference:

• Guidelines for Replacing SHA-1 certificates with SHA-2 on Thawte Trust Center
If you have additional questions, please contact your support team at
support@thawte.com.
Best regards,

Thawte Team

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑