TLS1.2/TLS1.1 ist schon wieder aus

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

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.

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?

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:

In der Tat jetzt alles über cloudflare

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...

(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?