Hallo, biite mal wieder TLS1.2 und/oder TLS1.1 aktivieren.
Es scheint jetzt hängt auch noch Cloudflare dazwischen? Schon etwas beunruhigend, wie da fast das ganze Internet mittlerweile dran zu hängen scheint... Und in der Datenschutzerklärung scheint davon auch nichts erwähnt zu werden.
SSL connection using TLSv1.2
SSL certificate verify ok.
----
* Trying 168.119.227.254...
* TCP_NODELAY set
* Connected to www.mikrocontroller.net (168.119.227.254) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection:
ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=www.mikrocontroller.net
* start date: Jan 9 16:08:09 2021 GMT
* expire date: Apr 9 16:08:09 2021 GMT
* subjectAltName: host "www.mikrocontroller.net" matched cert's
"www.mikrocontroller.net"
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after
upgrade: len=0
* Using Stream ID: 1 (easy handle 0x127de80)
> GET /topic/513561 HTTP/1.1
1 | * ALPN, offering h2 |
2 | * ALPN, offering http/1.1 |
3 | * successfully set certificate verify locations: |
4 | * CAfile: none |
5 | CApath: /etc/ssl/certs |
6 | * TLSv1.3 (OUT), TLS handshake, Client hello (1): |
7 | * CONNECT phase completed! |
8 | * CONNECT phase completed! |
9 | * TLSv1.3 (IN), TLS handshake, Server hello (2): |
10 | * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): |
11 | * TLSv1.3 (IN), TLS handshake, Certificate (11): |
12 | * TLSv1.3 (IN), TLS handshake, CERT verify (15): |
13 | * TLSv1.3 (IN), TLS handshake, Finished (20): |
14 | * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): |
15 | * TLSv1.3 (OUT), TLS handshake, Finished (20): |
16 | * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 |
17 | * ALPN, server accepted to use h2 |
18 | * Server certificate: |
19 | * subject: C=US; ST=California; L=San Francisco; O=Cloudflare, Inc.; CN=sni.cloudflaressl.com |
20 | * start date: Feb 21 00:00:00 2021 GMT |
21 | * expire date: Feb 20 23:59:59 2022 GMT |
22 | * subjectAltName: host "www.mikrocontroller.net" matched cert's "*.mikrocontroller.net" |
23 | * issuer: C=US; O=Cloudflare, Inc.; CN=Cloudflare Inc ECC CA-3 |
24 | * SSL certificate verify ok. |
25 | * Using HTTP2, server supports multi-use |
26 | * Connection state changed (HTTP/2 confirmed) |
27 | * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 |
28 | * Using Stream ID: 1 (easy handle 0x7fffd0f30f50) |
Jo, ...
$openssl ciphers -v | awk '{print $2}' | sort | uniq
SSLv3
TLSv1
TLSv1.2
TLS 1.1 gilt als unsicher und sollte nicht mehr verwendet werden. Und da das dann die Sicherheit aller Nutzer schwächt ist das eigentlich gar nicht schlecht dass das nicht geht. Viele Browser unterstützen das schon gar nicht mehr oder werden es bald entfernen Und auch TLS 1.2... eigentlich sollte jeder hinreichend moderne Browser TLS1.3 hinbekommen (also seit 2018 können Firefox und Chrome + Chrome-Derivate das), daher ist interessant wie dir das überhaupt aufgefallen ist...
@Einstein: Deinen Klugschiss kannst du fuer dich behalten. Deine als so sicher angepriesenen Browser werden ja wohl hoffentlich mit den besten Verfahren anfangen. > $openssl ciphers -v | awk '{print $2}' | sort | uniq > SSLv3 > TLSv1 > TLSv1.2 TLSv1.2 ist bei mir an. Und es tut sich trotzdem nichts. Der Browser baut die Verbindung auf, und bleibt dann bei 4/5 geladenen Seitenelementen haengen. Ursaechlich wohl bei einer Verbindung zu 151.101.114.109 Fastly/FFM.
SSL Labs: TLS ab 1.0 ist verfügbar, auch gestern Abend, alle 6 IPs. Client-Tests zu 2606:4700:20::681a:dfa: curl: TLS ab 1.2 funktioniert. wget: TLS ab 1.0 funktioniert. Firefox: TLS 1.0 funktioniert.
:
Bearbeitet durch User
Scheint diesmal eine andere Ursache zu haben (bei mir waren es vorher die fehlenden CBC-Modi - Browser ging nicht, openssl ging). Laut SSLLabs werden die jetzt angeboten, aber trotzdem bekomme ich nur einen lapidaren Handshake-Fehler:
1 | # openssl s_client -connect www.mikrocontroller.net:443 |
2 | CONNECTED(00000003) |
3 | 4156778760:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:757: |
4 | (server sendet nur 7 bytes: fatal handshake_failure, sonst nichts) |
5 | (ohne handshake nur noch dummy daten) |
6 | # openssl version |
7 | OpenSSL 1.0.1t 3 May 2016 |
Pfuscht cloudflare evtl dazwischen?
Es hängt davon ab, welche Ciphers der Client bei 1.0/1.1 mag. In 1.0/1.1 bietet der Server nur ECDHE_ECDSA_WITH_AES_128/256_CBC_SHA an. Wer das bei 1.0/1.1 nicht verdaut, sondern z.B. auf die älteren RSA/DHE Varianten besteht, der hat Pech.
:
Bearbeitet durch User
Update: zusätzlich "-servername www.mikrocontroller.net" und dann klappt es - bin mir aber ziemlich sicher, dass der Browser SNI kann, der bekommt trotzdem keine Verbindung.
> In 1.0/1.1 bietet der Server nur ECDHE_ECDSA_WITH_AES_128/256_CBC_SHA
an.
Jau, das wird es sein - CBC wird exklusiv nur bei Verfahren mit
Elliptischen Kurven angeboten, die mein Browser nicht kann.
Schon verrückt: Clients die EC können, können auch GCM und brauchen kein
CBC; die, die kein GCM können, können meist auch kein EC.
Tipp: die HTTP -> HTTPS redirection entfernen und den Inhalt einfach wieder in beiden Varianten anbieten! Da Google&Co inzw eh nur die HTTPS-Variante verlinken und bei den modernen Browsern HTTPS das default-Protokoll ist, landet der normale Traffic eh auf HTTPS - nur Leute wie ich, die explizit HTTP auswählen, landen auf der unverschlüsselten Seite.
foobar schrieb: > 4156778760:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 > Pfuscht cloudflare evtl dazwischen? ssl3 wird nicht akzeptiert. -tls1, -tls1_2 openssl s_client -connect mikrocontroller.net:443 -tls1
Ach du Heiland, hier merkt man echt gut, was für Dinosaurier hier unterwegs sind. Spiegelt die Digitalisierungsggedanken in der Politik sehr gut wieder.
Ich frage mich noch, unter welchen Umständen kommt man über Cloudflare, und unter welchen geht's direkt? @pong Scheint ja direkt drauf gekommen zu sein, während es bei mir über Cloudflare ging.
> ssl3 wird nicht akzeptiert. -tls1, -tls1_2
Das hatte ich ausprobiert, daran liegt es nicht:1 | # openssl s_client -connect www.mikrocontroller.net:443 -tls1 |
2 | CONNECTED(00000003) |
3 | 4156778760:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1315:SSL alert number 40 |
4 | 4156778760:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:637: |
5 | (...) |
6 | # openssl s_client -connect www.mikrocontroller.net:443 -tls1_2 |
7 | CONNECTED(00000003) |
8 | 4156778760:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:348: |
9 | (...) |
Was ich allerdings festgestellt habe: ein openssl s_client-connect nach www.mikrocontroller.net braucht zusätzlich ein "-servername www.mikronctroller.net". Ein connect nach mikrocontroller.net (ohne www.) geht auch ohne.
> Ich frage mich noch, unter welchen Umständen kommt man über Cloudflare, > und unter welchen geht's direkt? Ah, mal getestet: mikrocontroller.net geht direkt (und braucht kein SNI), schickt aber nur einen 301 nach https://www.mikrocontroller/xxx zurück, der dann über Cloudflare geht (und SNI braucht).
�� DPA �� schrieb: > Ich frage mich noch, unter welchen Umständen kommt man über Cloudflare, > und unter welchen geht's direkt? > > @pong Scheint ja direkt drauf gekommen zu sein, während es bei mir über > Cloudflare ging. Kann ich dir nicht sagen, mglw. kannst du dir etwas herauslesen. Verwendet wird noch OpenSSL 1.1.0 $openssl s_client -showcerts -connect mikrocontroller.net:443 CONNECTED(00000003) depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = www.mikrocontroller.net verify return:1 --- Certificate chain 0 s:/CN=www.mikrocontroller.net i:/C=US/O=Let's Encrypt/CN=R3 -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- 1 s:/C=US/O=Let's Encrypt/CN=R3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3 -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- --- Server certificate subject=/CN=www.mikrocontroller.net issuer=/C=US/O=Let's Encrypt/CN=R3 --- No client certificate CA names sent Peer signing digest: SHA256 Server Temp Key: X25519, 253 bits --- SSL handshake has read 3158 bytes and written 269 bytes Verification: OK --- New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 ..... usw.
�� DPA �� schrieb: > Ich frage mich noch, unter welchen Umständen kommt man über Cloudflare, > und unter welchen geht's direkt? > > @pong Scheint ja direkt drauf gekommen zu sein, während es bei mir über > Cloudflare ging. der genaue Ablauf ist mir noch nicht klar, Namensauflösung?! zitat: DNS Certificate Authority Authorization (CAA) Utilizing a DNS resource record lets domain owners decide which CAs are allowed to issue certificates for a given domain. If a CAA record exists, only the CAs listed in that record can issue the host’s certificate. https://protonmail.com/blog/tls-ssl-certificate/ ----------- $dig mikrocontroller.net type257 ; <<>> DiG 9.10.3-P4-Debian <<>> mikrocontroller.net type257 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56959 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;mikrocontroller.net. IN CAA ;; AUTHORITY SECTION: mikrocontroller.net. 10800 IN SOA ns1.first-ns.de. dns.hetzner.com. 2021020403 14400 1800 604800 86400 ;; Query time: 238 msec ;; SERVER: 91.239.100.100#53(91.239.100.100) ;; WHEN: Mon Feb 22 16:12:06 CET 2021 ;; MSG SIZE rcvd: 114 Nimm ggf. testweise andere Server in die resolv.conf auf, z.B. censurfridns.dk,freedns mglw. kommts dann von anderer Stelle? ;)
Mein Eindruck ist, der Webmeister hier hat sein "neues" Spielzeig mal wieder nicht im Griff. Weil, jetzt geht es wieder.
Ich hab's doch bereits geschrieben: "mikrocontroller.net" geht direkt nach Hetzner, "www.mikrocontroller.net" geht über CloudFlare. DNS hat entsprechend unterschiedliche Adress-Records: mikrocontroller.net. 197 IN A 168.119.227.254 vs www.mikrocontroller.net. 12 IN A 172.67.70.44 www.mikrocontroller.net. 12 IN A 104.26.12.250 www.mikrocontroller.net. 12 IN A 104.26.13.250
foobar schrieb: > Ich hab's doch bereits geschrieben: > "mikrocontroller.net" geht direkt nach Hetzner, > "www.mikrocontroller.net" geht über CloudFlare. Das passt aber auch nicht ganz zum beobachteten: pong schrieb: > Connected to http://www.mikrocontroller.net (168.119.227.254) port 443 Ich vermute, dass da einfach noch die alte Adresse gecached ist.
> Weil, jetzt geht es wieder.
Nachtrag: Natuerlich nicht von alleine.
Als kleiner Wuergaround gibt mein DNS fuer www... die alte
Adresse zurueck.
Mal guggn wie lang das haelt.
well www, censurfridns schickt mich zu 168.119.227.254 $dig @91.239.100.100 www.mikrocontroller.net ; <<>> DiG 9.10.3-P4-Debian <<>> @91.239.100.100 www.mikrocontroller.net ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45450 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;www.mikrocontroller.net. IN A ;; ANSWER SECTION: www.mikrocontroller.net. 10532 IN A 168.119.227.254 ;; AUTHORITY SECTION: mikrocontroller.net. 84486 IN NS robotns3.second-ns.com. mikrocontroller.net. 84486 IN NS robotns2.second-ns.de. mikrocontroller.net. 84486 IN NS ns1.first-ns.de. ;; ADDITIONAL SECTION: robotns2.second-ns.de. 58684 IN A 213.133.105.6 robotns3.second-ns.com. 4349 IN A 193.47.99.3 robotns3.second-ns.com. 172352 IN AAAA 2001:67c:192c::add:a3 ;; Query time: 250 msec ;; SERVER: 91.239.100.100#53(91.239.100.100) ;; WHEN: Mon Feb 22 17:15:02 CET 2021 ;; MSG SIZE rcvd: 226
www.mikrocontroller.net ist cloudflare cdn und leitet dann auf mikrocontroller.net bei Hetzner weiter? Was soll das für einen Sinn machen?
�� DPA �� schrieb: > Ich vermute, dass da einfach noch die alte Adresse gecached ist.
1 | Domain Name: MIKROCONTROLLER.NET |
2 | Registry Domain ID: 26384769_DOMAIN_NET-VRSN |
3 | Registrar WHOIS Server: whois.your-server.de |
4 | Registrar URL: http://www.hetzner.com |
5 | * Updated Date: 2021-02-21T18:49:55Z * |
6 | Creation Date: 2000-05-04T22:02:31Z |
7 | Registry Expiry Date: 2021-05-04T22:02:31Z |
8 | Registrar: Hetzner Online GmbH |
9 | Registrar IANA ID: 828 |
10 | Registrar Abuse Contact Email: abuse@hetzner.com |
11 | Registrar Abuse Contact Phone: +49 9831 5050 |
12 | Domain Status: ok https://icann.org/epp#ok |
13 | * Name Server: CRAIG.NS.CLOUDFLARE.COM * |
14 | * Name Server: LILITH.NS.CLOUDFLARE.COM * |
15 | DNSSEC: unsigned |
16 | URL of the ICANN Whois Inaccuracy Complaint Form: |
Ich habe das Gefühl, dass das Forum um einiges unzuverlässiger geworden ist, seit es Cloudflare nutzt. Immer wieder sehe ich z.B. "504 Gateway time-out" Fehler...
Es gab auch vorher gelegentliche Serverausfälle. Und den Server gibts ja wohl immer noch, Cloudflare ist nur zwischengeschaltet. Wenn dann wie vorhin der Server ausfällt, gibts nur eine andere Fehleranzeige, hübsch grafisch von Cloudflare statt lakonischer Nummer. Man kann wohl davon ausgehen, dass Cloudflare recht zuverlässig arbeitet. Und dass du es ziemlich schnell merkst, wenn nicht, denn dann kriegt das WWW insgesamt mehr Löcher als ein Schweizer Käse.
:
Bearbeitet durch User
Beitrag #6603738 wurde von einem Moderator gelöscht.
(prx) A. K. schrieb: > Es gab auch vorher gelegentliche Serverausfälle. Und den Server gibts ja > wohl immer noch, Cloudflare ist nur zwischengeschaltet. Wenn dann wie > vorhin der Server ausfällt, gibts nur eine andere Fehleranzeige, hübsch > grafisch von Cloudflare statt lakonischer Nummer. > > Man kann wohl davon ausgehen, dass Cloudflare recht zuverlässig > arbeitet. Und dass du es ziemlich schnell merkst, wenn nicht, denn dann > kriegt das WWW insgesamt mehr Löcher als ein Schweizer Käse. Mmh. https://support.cloudflare.com/hc/de/articles/205177068-Wie-funktioniert-Cloudflare- was man schnell merkt ist das die meisten freien anonproxies erstmal nicht mehr funktionieren, php-proxy, glype etc. klasse, prompt :( 504 Gateway Time-out nginx/1.19.5 @dpa /etc/hosts 168.119.227.254 www.mikrocontroller.net ;) ändert aber an der Sache nichts. --- der 91.239.100.100 anycast.censurfridns.dk. hat drei Tage gebraucht, jetzt zeigt er auch auf cloudflares DNS
(prx) A. K. schrieb: > Es gab auch vorher gelegentliche Serverausfälle. Und den Server gibts ja > wohl immer noch, Cloudflare ist nur zwischengeschaltet. Wenn dann wie > vorhin der Server ausfällt, gibts nur eine andere Fehleranzeige, hübsch > grafisch von Cloudflare statt lakonischer Nummer. Ein gataway timeout ist hier aber ein Spezialfall. Webbrowser haben oft recht lange timeouts, ein zwei Minuten liegen da schon drin. Bei Cloudflare bekomme ich den timeout viel schneller. Vermutlich zu schnell. Eventuell wäre die Seite ja noch gekomnen, wenn CF nicht aufgegeben hätte?
So speziell ist der 504 nicht. Den kann man beispielsweise auch von Webservern kriegen, die Probleme mit ihrem fast-cgi Backend auf der gleichen Kiste haben. Klar, es kann sein, dass Cloudflare früher schlapp macht. Das heisst aber nicht zwangsläufig, dass ein längeres Timeout sinnvoller sei. Sowas kommt ja nicht von garnix
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.