#tls

bkoehn@diaspora.koehn.com

Finally got the #DNS locked down at home. I had mis-configured #pfsense to do #DNSSEC verification itself, which disables DNS over #TLS (it would be nice if that was reflected in the UI and not just the documentation). Now the resolver that nearly everything uses works over #DoH (DNS over #HTTPS), and dig reports that my upstream resolver is doing DNSSEC verification for me (it reports ad as an answer flag).

Was finally able to confirm with #CloudFlare’s help page and by checking the firewall state for TCP connections open to port 853.

aktionfsa@diasp.eu

12.11.2023 Das EU-Vertrauen

Wollen wir Pflicht-Vertrauen in staatliche Stellen?

Vertrauen ist gut, Kontrolle ist besser. (Lenin)

Auf jeden Fall ist Vertrauen unheimlich wichtig. Gerade in Zeiten von Fake News und KI, die uns fast echt jeden Unsinn als Realität vorspielen kann. Ob im Internet eine Nachricht wirklich vom Absender kommt oder ob eine Webseite von der Domain xyz wirklich von dieser kommt oder ob sich ein Angreifer dazwischen geklemmt hat und mir seine "Wahrheit" unterjubelt, ist von entscheidender Bedeutung.

Deswegen hat man etwa vor 20 Jahren damit angefangen den Datenverkehr im Inernet möglichst verschlüsselt abzuwickeln und Sender und Empfänger mit Zertifikaten auszustatten, so dass sie ihre Identität beweisen können. Dazu wird mit TLS (Transport Layer Security) ein kryptografischer Schlüssel verwendet.

Unsere Browser kennen (die) vertrauenvollen Zertifizierungsstellen und markieren uns bei der Anzeige einer Webseite diese mit einem geschlossenen Schloss als sicher und vertraut. Welchen Zertifizierungsstellen vertraut wird und welchen nicht, entscheiden die Browserhersteller bisher selbst.

Die EU möchte nun den Regierungen der EU-Länder die Kontrolle über die "gültigen" kryptografischen Schlüssel für TLS geben. Dagegen haben inzwischen 400 weitere Unterzeichner aus der Wissenschaft einen offenen Brief von 38 IT-Sicherheitsforschern aus dem Jahr 2022 unterzeichnet. Ihre Kritik wendet sich nicht nur gegen eine weitere staatliche Regulierung des Internets, sie stellen auch wieder einmal fest, dass solche Maßnahmen an der technischen Realisierbarkeit vorbeigehen.

"Der Gesetzentwurf konzentriert sich auf die Browser-Nutzung von TLS, aber TLS wird weitaus umfassender als nur im Internet eingesetzt", kritisierte laut Heise.de im vorigen Jahr Vinton G. Cerf, einer der "Väter des Internet" und derzeit Google-Mitarbeiter. Aber auch die Browser stellt das Vorhaben vor Schwierigkeiten. Soll künftig der Internetverkehr von Stellen aus der EU als vertrauenswürdiger angesehen werden, als Daten von außerhalb? Das würde dann neben dem geöffneten Schloss (unsicher) noch "gute" und "weniger gute" geschlossene Schlösser verlangen, auch eine räumliche Beschränkung der EU-TLS-Variante auf das Unionsgebiet ist technisch nicht umsetzbar. Dürfen dann EU Zertifizierungsstellen auch Schlüssel für nicht in der EU beheimatete Firmen oder Töchter ausstellen und sind diese dann mehr wert?

Staatliches Schloss - gut oder böse?

Ein negatives Beispiel: So hat z.B. die Regierung Kasachstans ihren Bürgern im Jahr 2020 ein eigenes Wurzelzertifikat aufgedrängt, um deren verschlüsselten Datenverkehr mitlesen zu können. Ähnliches können diese oder jene Staaten wieder anderen unterstellen, was am Ende zu nationalen Netzen führen und das gegenseitige Vertrauen völlig zerstören würde.

Die Autoren des offenen Briefs kritisieren auch die geplante European Digital Identity Wallet (EU-Id-Brieftasche), die wichtige Nachweise für die grenzüberschreitende Nutzung auf dem Smartphone bündeln soll. Denn dort wären Zugriffe auf persönliche Aktivitäten der Nutzer möglich, weil die EU Gesetzgebung vorsieht, dass beispielsweise Regierungen Kenntnis über die Verwendung von Anmeldeinformationen aus der ID-Wallet bei Anwendung in diversen Lebensbereichen erlangen können – von Gesundheit, Finanzen, Online-Aktivitäten bis hin zu öffentlichen Verkehrsmitteln. Heise.de zitiert die Unterzeichner, die "die Privatsphäre der EU-Bürger erheblich gefährdet" sehen.

Fazit: die staatliche Überwachung wird weiter wachsen, ansonsten wird durch das Vorhaben nichts besser, aber vergessen wir nicht, dass im Jetzt-Zustand diese persönlichen Informationen bei irgendwelchen angeblich vertrauensvollen privaten Instanzen landen, wo sie auch missbraucht werden können ...

Mehr dazu bei https://www.heise.de/news/Hunderte-Wissenschaftler-warnen-vor-staatlichen-Root-Zertifikaten-9355165.html
Kategorie[21]: Unsere Themen in der Presse Short-Link dieser Seite: a-fsa.de/d/3xg
Link zu dieser Seite: https://www.aktion-freiheitstattangst.org/de/articles/8584-20231112-das-eu-vertrauen.htm
Link im Tor-Netzwerk: http://a6pdp5vmmw4zm5tifrc3qo2pyz7mvnk4zzimpesnckvzinubzmioddad.onion/de/articles/8584-20231112-das-eu-vertrauen.html
Tags: #EU-Vertrauen #Verbraucherdatenschutz #Datenschutz #Datensicherheit #TLS #TransportLayerSecurity #Browser #Zertifizierungsstellen #SecurityChain #FakeNews #Zensur #Transparenz #Informationsfreiheit #Internetsperren #Netzneutralität #OpenSource #Privatsphäre

prplcdclnw@diasp.eu

Post-Quantum Cryptography: Another Candidate Falls

NIST has already selected CRYSTALS-KYBER as a quantum-resistant TLS algorithm, but was still considering four others for future selection. Now only three.

SIKE has been broken, with an ordinary PC. Now it's just BIKE, Classic McEliece, and HQC as possible alternatives to CRYSTALS-KYBER.

https://csrc.nist.gov/Projects/post-quantum-cryptography/round-4-submissions
https://csrc.nist.gov/Projects/post-quantum-cryptography/selected-algorithms-2022
https://arstechnica.com/information-technology/2022/08/sike-once-a-post-quantum-encryption-contender-is-koed-in-nist-smackdown/

#cryptography #quantum-computer #quantum-computers #quantum-computing #privacy #safety #security #surveillance #tls #transport-security

bkoehn@diaspora.koehn.com

Alright, after a bit more puttering about I've got my #k3s #Kubernetes cluster networking working. Details follow.

From an inbound perspective, all the nodes in the cluster are completely unavailable from the internet, firewalled off using #hetzner's firewalls. This provides some reassurance that they're tougher to hack, and makes it harder for me to mess up the configuration. All the nodes are on a private network that allows them to communicate with one another, and that's their exclusive form of communication. All the nodes are allowed any outbound traffic. The servers are labeled in Hetzner's console to automatically apply firewall rules.

In front of the cluster is a Hetzner firewall that is configured to forward public internet traffic to the nodes on the private network (meaning the load balancer has public IPv4 and IPv6 addresses, and a private IPv4 address that it uses to communicate with the worker nodes). The load balancer does liveness checks on each node and can prevent non responsive nodes from receiving requests. The load balancer uses the PROXY protocol to preserve source #IP information. The same Hetzner server labels are used to add worker nodes to the load balancer automatically.

The traffic is forwarded to an #nginx Daemonset which k3s keeps running on every node in the cluster (for high availability), and the pods of that DaemonSet keep themselves in sync using a ConfigMap that allows tweaks to the nginx configuration to be applied automatically. Nginx listens on the node's private IP ports and handles #TLS termination for #HTTP traffic and works with Cert-Manager to maintain TLS certificates for websites using #LetsEncrypt for signing. TLS termination for #IMAP and #SMTP are handled by #Dovecot and #Postfix, respectively. Nginx forwards (mostly) cleartext to the appropriate service to handle the request using Kubernetes Ingress resources to bind ports, hosts, paths, etc. to the correct workloads.

The cluster uses #Canal as a #CNI to handle pod-to-pod networking. Canal is a hybrid of Calico and Flannel that is both easy to set up (basically a single YAML) and powerful to use, allowing me to set network policies to only permit pods to communicate with the other pods that they need, effectively acting as an internal firewall in case a pod is compromised. All pod communication is managed using standard Kubernetes Services, which behind the scenes simply create #IPCHAINS to move traffic to the correct pod.

The configuration of all this was a fair amount of effort, owing to Kubernetes' inherent flexibility in the kinds of environments it supports. But by integrating it with the capabilities that Hetzner provides I can fairly easily create an environment for running workloads that's redundant and highly secure. I had to turn off several k3s "features" to get it to work, disabling #Traefik, #Flannel, some strange load balancing capabilities, and forcing k3s to use only the private network rather than a public one. Still, it's been easier to work with than a full-blown Kubernetes installation, and uses considerably fewer server resources.

Next up: storage! Postgres, Objects, and filesystems.