Ok, dachte schon ich hätte was verpasst und Nginx würde die andere Openssl Api verwenden und ich hätte das in den Release Notes überlesen - dann bleibt es erstmal weiterhin bei 90% Cipher Strength 
Posts by douzer
-
-
100% bekommt man nur, wenn man schlechtere, aber standardkonforme Crypto erlaubt.
Wie habt ihr beim Nginx die TLS1.3 Ciphers angepasst ?
-
Ich kann ebenfalls bestätigen, dass acme.sh in Kombination mit der Netcup DNS API einwandfrei funktioniert.
-
Teilweise gar nicht mehr ganz sooooo unüblich. Google macht das schon länger.
Ich war da eher positiv überrascht, dass das ich auch bei kleineren wie Datev, etc. mittlerweile normal ist.
-
Und wieso geht der Raspi offline, wenn du Pihole Updates?
Ich hab gerade 2 per SSH updated und Beide laufen fein - die Raspis wären aber auch bei einem fehlgeschlagenen Upgrade gelaufen.
-
und ob es jetzt ein Händler ist, dem die A-Karte gezeigt wird, oder einem Erben ist unerheblich; Apple hat hier definitiv Mist gebaut
Wenn du es als Mist ansiehst, dass jeder dahergelaufene und ja ich meine hier auch den Händler, Geräte wieder in Betrieb nehmen kann - dann hat Apple natürlich Mist gemacht.
Wenn der Händler jedoch Waren verkaufen will und nicht weiß, was hier alles auf ihn zukommen kann, bzw. was er denn alles prüfen müsste - wer da dann wohl Mist gebaut hat, das überlasse ich jetzt dem Leser ....
-
Doch das ist ein Designfehler, und nein es ist nicht Schuld desjenigen, der das Gerät vor dem Verkauf nicht zurücksetzt;
Wieso ist es ein Designfehler, wenn nicht jeder einfach das Gerät verwenden kann, wenn es der eigentliche Besitzer nicht frei gibt?
Das ist/war der Sinn des T2 Chips und allen anderen Maßnahmen um gestohlene Geräte unbrauchbar zu halten.
-
US-Exportbeschränkungen?
Wenn die das als Export Cipher liefern, wärs ja noch erträglich
-
Ich wollte immer warten bis Letsencrypt ECDSA Intermediate oder Root-Zertifikate hat. Aber da das wohl doch noch länger dauert, habe ich das dann beim buster update mit gemacht.
Es steht aber mittlerweile auf den kommenden Features - Upcoming Features
-
Ich würde aber trotzdem sagen, dass sich die Technik in fast 15 Jahren etwas verändert hat
Und man immer nur die Leute meckern hört, wo es zu Problemen kommt.
Die mehrheitlich anderen Installationen vergleicht keiner - auch nicht im Verhältnis.
Vielleicht sollte man dort, wo es zu Problemen kommt, auch mal die gesamte restliche Installation hinterfragen
-
das sagen Autofahrer auch immer - is ja Benz und net Skoda
- und fahren wie die gesengten;Och, so ein Oktavia RS dachte letztens auch, er kann mich im Benz ärgern
-
Es wird gar kein DANE Record angezeigt.
Was sagt denn z.B. https://check.sidnlabs.nl/dane/ oder https://dane.sys4.de/smtp/douzer.de ?
-
Wäre mir nicht bekannt. Der Hostname bzw. FQDN des Mailservers nutzt die selbe Domain und die ist ja wie gesagt in Ordnung... durch ein Relay gehen die Mails nicht nochmal, von daher sollte das alles passen.
Habe es bei mir gerade getestet. Zeigt er im Ergebnis unter Advanced bei den MX Records nichts genaueres an, was nicht passt?
-
Wenn ich weiß, dass da Müll kommt und keine TCP Verbindung bestätige, weiß der sendende Server das - ich schicke ihm kein 250 OK.
Microsoft schickt mir ein 250 OK und packt die Mail trotzdem direkt in den Müll.
Das ist ein Unterschied.
Naja, bitte nicht nur halbe Sätze zitieren, die dann irgendwie in die Argumentation passen ....
Die Aussage zur Netzneutralität ziehe ich sehr wohl in Zweifel, da dieser Kontext nichts und auch gar nichts, mit Netzneutralität, geschweige denn mit der Verletzung selbiger zu tun hat.
Früher gab es mal einen netten Grundsatz, der hoch gelobt wurde: Netzneutralität.
Packete sollen nicht anhand ihrer Metadaten diskriminiert werden. SRC-IP ist ein Metadatum.
Und ich bleibe dabei, dass das nicht annehmen von Mails von klar bekannten Spammern nichts mit einer Verletzung der Netzneutralität zu tun hat ....
-
Früher gab es mal einen netten Grundsatz, der hoch gelobt wurde: Netzneutralität.
Packete sollen nicht anhand ihrer Metadaten diskriminiert werden. SRC-IP ist ein Metadatum.
RBLs und Dailin Ranges fallen hier aber ebenso drunter und hier hat es sich schon ein wenig bewährt, in einem größeren Ganzen generell zu blocken - ich möchte damit nur sagen, dass es generell nicht verwerflich ist, Mails anhand ihrer SRC-IP direkt zu verwerfen, wenn ich bei der Verbindung des gegnerischen MTAs bereits weiß, dass es Mist ist.
-
LetsEncrypt ist überhaupt nicht vertrauenswürdig!!11!!!11!!elf!11!!!
Was nichts kostet, taugt nichts ....
-
Habe nun DenyHosts oder fail2ban entdeckt, werde vermutlich eines von beiden testen. Kann jemand Erfahrungen dazu teilen?
Nimm fail2ban. DenyHosts wird nicht mehr weiterentwickelt. Abgesehen davon kannst du mit fail2ban viele andere Services ebenfalls prüfen lassen.
-
Vodafone ist bei Peerings gleich bis schlimmer als die Telekom? Wofür haben sie dann 1200 Gbit und 900 Gbit am DE-CIX?
Da wär jetzt wohl die Quelle interessant, da selbst Vodafone dies wohl anderst sieht - https://www.peeringdb.com/asn/3209
Ports an einem IX heißt nicht, dass öffentlich mit allen gepeert wird .... -
Als nicht Telekom Kunde würde ich das Routing Verdächtigen.
Es ist ja hinreichend bekannt, dass die Telekom nicht der peeringfreundlichste ISP ist. In Verbindung mit einer anderen routenführung bei v6 könntest du Pech haben und an einem peering Engpass vorbeikommen.
Ohne Traceroutes nicht bewertbar.
Vodafone und Konsorten verhalten sich gleich bis schlimmer, nur dass man bei der Telekom, im vergleich zu den Anderen immer einen Dual-Stack Anschluß bekommt.
-
die mögliche Kilometerleistung eines Reifensatzes hängt nicht unwesentlich davon ab,
wieviel Zeit zwischen Produktion und tatsächlicher erstmaliger Verwendung liegt;
je länger dieser Zeitraum umso mehr km sind möglich;
Da magst du nicht ganz unrecht haben, das darf auch gerne wer für sich ausprobieren.
Ich zieh es aber vor, nicht mit alten harten Reifen im Strassenverkehr teilzunehmen ....
