Datenhaufen zu IT und Elektronik.

Autor: kernel-error (Seite 21 von 48)

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

IPv6 Buch von Jens Link

Ich räume gerade etwas auf und da finde ich einen Merker für das IPv6 Buch von Jens Link…. Eigentlich etwas dass ich mir in den „Schrank“ stellen wollte. Leider scheint es noch immer nicht kaufbar 🙁 So als einfaches „Einsteigerbüchlein“ schien es mir perfekt. Schade… Werde es dann wohl mal aus meiner Merkliste löschen.

http://www.amazon.de/IPv6-Planung-Umstieg-Jens-Link/dp/3937514899

Komisch, oder?

So long…

Abwasserrohr

Mal etwas ganz anderes…. Keine Ahnung was ihr so zwischen den Feiertagen macht, ich repariere kaputte Abwasserrohre. Mit Vorliebe hinter der Dusche!

Nein, Scherz! Zumindest zum Teil… Irgendwas machte seit kurzem hinter der Dusche meiner Kinder „Probleme“. Irgendwo in der Wand war etwas undicht. Zwischen den Feiertagen hatte ich Zeit, so zumindest die Einschätzung meiner Frau 😛

Also habe ich alles auf gestemmt und ganz zuletzt das Problem gefunden. Das Abwasserrohr vom Waschbecken war dort undicht. Getauscht und jetzt muss ich wohl eine neue Dusche bauen, TOP.

Es will nicht zufällig jemand helfen?

TLS Protokol und Cipher Informationen im Mail Header – Postfix

Als kleiner Postfix Tipp am Rande…. Wenn man gerade mit seinen TLS Einstellungen „herumspielt“, kann es helfen die groben Informationen für jede E-Mail nicht immer aus dem Logfile sammeln zu müssen.

Postfix bietet die schnelle Möglichkeit, genau diese Informationen einfach mit in den Mail Header zu packen.

Folgende Konfigurationserweiterung ist dafür nötig:

/etc/postfix/main.cf:
smtpd_tls_received_header = yes

Ab diesem Moment finden sich Informationen wie die unten stehende in eingehenden E-Mails.

So long….

Received: from mx01.domain.de (mx01.domain.de [1.2.3.4])
    (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits))
    (No client certificate requested)
    by smtp.kernel-error.de (Postfix) with ESMTPS id 245478112D9
    for <kernel-error@kernel-error.com>; Wed, 17 Dec 2014 05:15:10 +0100 (CET)

Postfix elliptische Kurven nach Diffie-Hellman – EECDH in groß

Kex exchange basierend auf EECDH (diese elliptischen Kurven nach DH Diffie-Hellmann), sollte ja inzwischen ein alter Hut sein. Ich gehe also mal von einer aktivieten und funktionsfähigen Konfiguration aus (irgendwo habe ich das wohl auch schon mal beschrieben).

Im Standard läuft dieses nun bei 1024bit also EECDH mit ca. 128bit (smtpd_tls_eecdh_grade=strong). Möchte man alles auf 2048bit EECDH mit ca. 192bit aufbohren… Was ca. die doppelte „Sicherheit“ zu EECDH mit 128bit bedeutet, dann ist folgendes zu erledigen.

Zuerst benötigen für eine große prime group:

$ cd /etc/postfix
$ openssl dhparam -out dh_2048.tmp 2048 && mv dh_2048.tmp dh_2048.pem
$ chmod 644 dh_2048.pem

Dann Postifix mitteilen, dass er sie bitte nutzten soll (ist kein Typo, gehört zur Option „smtpd_tls_dh1024_param_file„). 

/etc/postfix/main.cf:
    smtpd_tls_dh1024_param_file = /etc/postfix/dh2048.pem
    smtpd_tls_dh512_param_file = /etc/postfix/dh512.pem

Nun wechselt smtpd_tls_eecdh_grade von strong zu ultra und ich setzte noch die zu verwendende „Kurve“ fest.

/etc/postfix/main.cf:
    smtpd_tls_eecdh_grade = ultra
    tls_eecdh_strong_curve = prime256v1
    tls_eecdh_ultra_curve = secp384r1

Diese Aktion könne nicht ganz Schmerzfrei sein 🙂 Für privat und mein Testsystem sicher zu verantworten. Manche MSA (Mail SUbmission Agent) könnten damit Probleme bekommen. Hat also jemand ein Problem mit E-Mail zu senden, bitte melden 😀

So long….

TLS_FALLBACK_SCSV Debian 7 Wheezy OpenSSL 1.0.1e to 1.0.1j Upgrade

Wer bei seinem Debian TLS_FALLBACK_SCSV im Apache nutzen möchte, muss im Grunde nur auf eine OpenSSL Version >=1.0.1j wechseln.

Einen direkten Backport gibt es dafür leider nicht, also selbst übersetzten. Dazu nutzt man einfachsten direkt den „Debian-Weg“.

Vorbereiten fürs Kompilieren:

$ cd /usr/src
$ apt-get install build-essential fakeroot
$ apt-get build-dep openssl

Herunterladen der aktuellen Version:

$ wget http://ftp.de.debian.org/debian/pool/main/o/openssl/openssl_1.0.1j-1.dsc
$ wget http://ftp.de.debian.org/debian/pool/main/o/openssl/openssl_1.0.1j.orig.tar.gz
$ wget http://ftp.de.debian.org/debian/pool/main/o/openssl/openssl_1.0.1j-1.debian.tar.xz

Auspacken des Archives und mit den Patchen „verknüpfen“:

$ dpkg-source -x openssl_1.0.1j-1.dsc

Ins neue Verzeichnis wechseln:

$ cd openssl-1.0.1j

Kompilieren und deb Pakete erstellen:

$ dpkg-buildpackage -us -uc -rfakeroot

Die neuen Pakete installieren:

$ cd ..
$ dpkg -i libssl1.0.0_1.0.1j-1_amd64.deb libssl1.0.0-dbg_1.0.1j-1_amd64.deb libssl-dev_1.0.1j-1_amd64.deb libssl-doc_1.0.1j-1_all.deb openssl_1.0.1j-1_amd64.deb

Kontrolle der Version:

$ openssl version
OpenSSL 1.0.1j 15 Oct 2014

ACHTUNG… Ab diesem Moment ist man natürlich selbst dafür verantwortlich Pachte zu installieren 😀

So long…..


Selbstverständlich profitieren damit alle Anwendungen, die auf OpenSSL aufbauen, so auch Postfix, Dovecot usw:

$ openssl s_client -connect smtp.kernel-error.de:465 -fallback_scsv -no_tls1_2
CONNECTED(00000003)
140410198378152:error:1407743E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert inappropriate fallback:s23_clnt.c:770:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 215 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

U-P-D-A-T-E

Denkt an die Updates 😀

$ openssl version
OpenSSL 1.0.1k 8 Jan 2015

Internet gefunden und weiterer Quatsch…

Man was war heute ein fauler Tag… und es war wunderbar. Es passiert mir einfach viel zu selten, dass ich mal so einen richtig faulen und sinnfreien Tag habe 🙂

Spät aufgestanden, Frühstück war vorbereitet, Internet von Level3 gefunden, die Katze mit einem Foto geweckt (er hasst das :-P), für Autohaus die Reifendaten eingesammelt, etwas vorm Schallplattenspieler herumgelegen, den Hund sowie mich bewegt, ein Upgrade am FreeNAS gefahren und noch rsync vom Ampache (über eine viel zu langsame Internetverbindung) angeworfen.

Tja Leute…. Jetzt gleich noch Tatort und Bier, dann schön schlafen. Morgen ist ja wieder arbeiten angesagt!

Vielleicht ist es ganz gut, dass man nicht SO viele faule Tage hat. Am Ende wird einem nur Langweilig!

Sabayon Linux – equo / Entropy Geschwindigkeit erhöhen

Die im Standard voreingestellten Optionen vom Entropy sind bei Sabayon nicht ganz optimal, zumindest wenn man hinter einem normalen Internetanschluss sitzt.

Um nun die Downloadgeschwindigkeit etwas zu erhöhen gibt es ein paar Dinge, die man tun kann.

Als erstes sollte man, den für seinen Standort, besten Spiegelserver herausfinden. Dieses erledigt folgender Aufruf:

$ sudo equo repo mirrorsort sabayon-weekly

Voreingestellt für den gleichzeitigen Download sollte 3 sein. Ab einem normalen A-DSL Anschluss darf man diese Zahl gerne auf 10 ändern.

$ sudo vi /etc/entropy/client.conf
multifetch = 10

Oft ist der eigentliche Unterschied zwischen zwei Paketen, bei einem Upgrade, eher gering. Daher macht es Sinn sich auch nur diesen Unterschied herunter zu laden:

$ sudo vi /etc/entropy/client.conf
packages-delta = enable

So, viel Spaß!

Temperaturmessung mit dem Raspberry Pi und DHT22-Sensor

Meine Wetterstation hat aufgegeben 🙁 OK, wirklich interessant war für mich immer nur Luftfeuchtigkeit und Temperatur draußen. Diese Aufgabe sollte doch von meinem Raspberry Pi erfüllt werden können, oder? Dann hätte ich die Daten zusätzlich direkt in meinem Cacti!

Ich setzte dabei auf den DHT22 / AM2302. Über Amazon war dieser für 2€ schnell bestellt. Ein 4,7kΩ Widerstand hatte ich selbstverständlich noch. Das eigentliche Schaltbild ist nicht weiter der Rede wert, ich habe da ein Bild für euch weiter unten…

Zur Software…

Nötig ist git für wiringPi und lol_dht22

Erstmal eine root Konsole auf dem Raspberry Pi öffnen:

$ sudo /bin/bash

Alle Tools für git installieren:

$ apt-get install git-core

Dann einen clone von wiringPi ziehen und kompilieren:

$ git clone git://git.drogon.net/wiringPi
$ cd wiringPi
$ ./build
$ cd ..

Jetzt noch schnell lol_dht22, dieses Programm liest den eigentlichen Sensor aus.

$ git clone https://github.com/technion/lol_dht22
$ cd lol_dht22
$ ./configure
$ make

Damit sollte sich bereits der Sensor auslesen lassen:

$ ./loldht 7
Raspberry Pi wiringPi DHT22 reader
www.lolware.net
Data not good, skip
Humidity = 73.90 % Temperature = 9.30 *C

Perfekt 😀 Nun benötige ich natürlich nur die beiden Zahlen. Daher habe ich den Code etwas angepasst. So bekomme ich jetzt nur noch die beiden Werte beim Aufruf:

$ /lol_dht22/loldht 7
73.90
9.30

Diese sammle ich nun per Bash-Script über einen Cron-Job ein und lege sie in zwei Files.

$ crontab -l
* * * * * /var/scripts/getsensor.sh

Hier das vom Cron aufgerufene Script:

$ cat /var/scripts/getsensor.sh
#!/bin/bash

/lol_dht22/loldht 7 > /home/pi/both.txt

 
while [ ! -s "/home/pi/both.txt" ]
do
        sleep 5
        /lol_dht22/loldht 7  > /home/pi/both.txt
 
done

sed '2d' /home/pi/both.txt > /home/pi/humid.txt
sed '1d' /home/pi/both.txt > /home/pi/temp.txt

Damit liegen nun immer die aktuellen Werte für Temperatur und Luftfeuchtigkeit in den beiden Textfiles unter /home/pi.

Jetzt sollen diesen Daten natürlich noch per snmp abgerufen werden können, damit ich sie in Cacti einbinden kann. Also zuerst snmp auf dem Raspberry Pi installieren:

$ apt-get install snmp snmpd

Unter „Pass-through“ MIB extension command lege ich nun zwei weitere an, für Temperatur und Luftfeuchtigkeit:

pass .1.3.6.1.2.1.25.1.8.2      /bin/sh         /usr/local/bin/temp
pass .1.3.6.1.2.1.25.1.8.1      /bin/sh         /usr/local/bin/humid

Wird nun per snmp diese OID abgefragt, wird das zugehörige Script ausgeführt:

$ cat /usr/local/bin/temp
#!/bin/bash
echo .1.3.6.1.2.1.25.1.8.2
echo gauge
cat /home/pi/temp.txt
$ cat /usr/local/bin/humid
#!/bin/bash
echo .1.3.6.1.2.1.25.1.8.1
echo gauge
cat /home/pi/humid.txt

Als kleiner Test:

$ snmpget -c public -v1 errorpi .1.3.6.1.2.1.25.1.8.1
iso.3.6.1.2.1.25.1.8.1 = Gauge32: 76

$ snmpget -c public -v1 errorpi .1.3.6.1.2.1.25.1.8.2
iso.3.6.1.2.1.25.1.8.2 = Gauge32: 9

Dieses lässt sich nun im Cacti einbinden und so aufzeichnen. Ok, etwas von hinten durch die Brust ins Auge… Sicher optimiere ich dieses noch 😀

Ach ja,  wer es braucht… Die Template-Exports für Cacti sind hier: cacti-temp.tar.gz


Und wohin mit dem Teil? Diese Frage hat mich etwas beschäftigt. Ich wollte es draußen haben, denn ich brauche ja die Daten von draußen 😀 Dafür muss es geschützt vor Wasser sein. Um die Luftfeuchtigkeit messen zu können darf es denn noch nicht komplett verschlossen sein. Ebenfalls sollte es an einer Stelle hängen, an welcher es nicht zu schlecht aussieht und vor allem, an welcher es nicht zerstört wird.

Ich habe einfach ein Rohr genommen, den Sensor dort mit etwas Silikon „eingeklebt“ und das Rohr an einer Seite mit einem Deckel verschlossen. So sollte kein Wasser an den Sensor laufen können. Angebracht habe ich dieses Rohr an meinem Pfosten der Satellitenschüssel. Dort oben „steht“ die Luft eher selten und es kommt niemand ran. Zusätzlich fällt es dort nicht weiter auf.

Mal abwarten wie es sich dort oben macht. Vielleicht hänge ich es später noch mal um! Sobald sich die eigentliche Position gefestigt hat, wird dann auch der Raspberry PI ordentlich verstaut ;-P


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
« Ältere Beiträge Neuere Beiträge »

© 2025 -=Kernel-Error=-

Theme von Anders NorénHoch ↑