Das längste Thema

  • Ich erinnere mich an die Diskussion über das Spielen unter Linux. Gerade das Video gesehen und ich war echt begeistert,wie weit es schon gekommen ist:

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

  • Hast Du ein Smartphone um die Fire TV App zu installieren? Wenn ich mich richtig erinnere konnte man dort Copy&Paste vom Passwortmanager machen.

    Hast recht, das geht ja auch...


    Aber ansonsten hat YouTube das auch ganz gut gelöst. Zum Koppeln mit dem Fernseher muss man in der App nur einen 8 (?) Zeichen Code aus Buchstaben eingeben und dann war's das. Möchte man sich mit dem Konto selbst anmelden, bekommt man auch so einen Code und kann sich auf youtube.com/activate mitsamt Code und Konto anmelden und am firetv selber muss man gar nichts machen!

  • Warum sollte der abfackeln? Er hat doch extra in einem Video gezeigt das sein "Dämm-Material" nicht brennbar ist, war glaub sein Aprilscherz ^^ Finde ihn ansonsten auch ganz unterhaltsam.

    Weniger Luftvolumen + keine Wärmebrücke über die Wände + Luftauslass wurde reduziert = das könnten Server nicht so dolle finden. Warum rauchen dem ständig nochmal die NAS / SAN Systeme ab? Was erwartet man denn da, wenn der Raum ganze 2m³ Luft hat?


    Die einzigen nützlichen Videos kommen von seinen Mitarbeitern. Ansonsten muss ich bei den Videos immer nur den Kopf schütteln.

    Was ich auch nicht verstehe, wenn er einen Computer baut, warum er ständig alle Teile 4free bekommt.

  • Ich experimentiere gerade zum ersten Mal mit certbot. Es soll bei diesem Szenario absichtlich kein alternativer Client genutzt werden.


    Sehe ich das richtig, dass man bei gleichzeitiger Nutzung von RSA und ECDSA Zertifikaten noch immer möglichst viel selbst erledigen muss, wenn sich der Publickey nicht andauernd ändern soll? (Stichwort TLSA-Record)


    D.h. den Key und CSR für beide Varianten erstellen und nachher das Zertifikat mit certbot certonly anfordern. Um die Verlängerung bzw. den Speicherort kümmert man sich besser selbst mit einem kleinen Script.


    Oder habe ich irgendeinen supertollen modernen Weg übersehen? Genutzt wird übrigens Debian Buster, die eingesetzten Versionen sollten somit aktuell sein.




    Edit, wenn man schon mal am Testen ist: Mit OpenSSL 1.1.1 aus Experimental klappt dann auch schon TLSv1.3 über Nginx 8o


    tls13-summary.png tls13-configuration.png


    (Let's Encrypt Staging; deshalb nicht vertrauenswürdig)

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    3 Mal editiert, zuletzt von KB19 ()

  • Weniger Luftvolumen + keine Wärmebrücke über die Wände + Luftauslass wurde reduziert = das könnten Server nicht so dolle finden. Warum rauchen dem ständig nochmal die NAS / SAN Systeme ab? Was erwartet man denn da, wenn der Raum ganze 2m³ Luft hat?


    Die einzigen nützlichen Videos kommen von seinen Mitarbeitern. Ansonsten muss ich bei den Videos immer nur den Kopf schütteln.

    Was ich auch nicht verstehe, wenn er einen Computer baut, warum er ständig alle Teile 4free bekommt.

    Es gab tatsächlich noch ein paar Anpassungen an dem Raum, weil sie selber festgestellt haben, dass es zu wenig Luft ist ^^

  • [U]nd vor allem wie würdest Du das in Apache einbauen?

    Beispielsweise so (kann man bspw. über hardenize.com bequem verifizieren):

    Code
    # [...]
    SSLCertificateKeyFile /mirrored/gluster/mounts/shared/certificates/letsencrypt/dns-live/pz_rsa_key.pem
    SSLCertificateFile /mirrored/gluster/mounts/shared/certificates/letsencrypt/dns-live/pz_rsa_cert.pem
    SSLCertificateKeyFile /mirrored/gluster/mounts/shared/certificates/letsencrypt/dns-live/pz_ecdsa_key.pem
    SSLCertificateFile /mirrored/gluster/mounts/shared/certificates/letsencrypt/dns-live/pz_ecdsa_cert.pem
    SSLCertificateChainFile /mirrored/gluster/mounts/shared/certificates/letsencrypt/dns-live/letsencrypt_chain.pem
    # [...]

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Sehe ich das richtig, dass man bei gleichzeitiger Nutzung von RSA und ECDSA Zertifikaten noch immer möglichst viel selbst erledigen muss, wenn sich der Publickey nicht andauernd ändern soll? (Stichwort TLSA-Record)


    D.h. den Key und CSR für beide Varianten erstellen und nachher das Zertifikat mit certbot certonly anfordern. Um die Verlängerung bzw. den Speicherort kümmert man sich besser selbst mit einem kleinen Script.


    Oder habe ich irgendeinen supertollen modernen Weg übersehen? Genutzt wird übrigens Debian Buster, die eingesetzten Versionen sollten somit aktuell sein.

    Bei ECDSA Zertifikaten, nein (nichts übersehen). Bei RSA Zertifikaten kannst du die Option --reuse-key nutzten, um zu verhindern, dass sich der Key dauernd ändert.


    Ich hoffe ja, dass es die OpenSSL 1.1.1. noch nach Buster schafft.

  • Zertifikate... Erwähnt doch mal bei den managed private Server, dass man dort überhaupt und mehr als 1 LetsEncrypt Zertifikat nutzen darf. ;)

    "Security is like an onion - the more you dig in the more you want to cry"

  • Zitat

    Die Standardisierung des Protokolls TLS 1.3 ist schon so weit fortgeschritten, dass immer mehr Software die Vorabversionen des kommenden Standards unterstützt. Dazu gehört auch der freie Webserver Nginx in der nun verfügbaren Version 1.13. Der Nachteil daran ist zurzeit aber noch, dass OpenSSL TLS 1.3 offiziell erst in Version 1.1.1 unterstützen wird, die noch nicht erschienen ist.


    Nginx-Nutzer, die TLS 1.3 testen möchten, müssen also gegen eine instabile Version von OpenSSL kompilieren. Darüber hinaus ist darauf zu achten, die Draft-18-Version von TLS 1.3 in OpenSSL zu verwenden, da etwa die Browser Firefox und Chrome bisher nur diese Version unterstützen.

    Quelle: https://www.golem.de/news/webs…-support-1704-127503.html


    denke mal Golem ist vertrauenswürdiger als manche Blogs

  • ob TLS1.3 dann so kommt und vor allem auch Verbreitung findet, ist aber fragwürdig;

    weil was die HTTP WG bei der IETF schon pfuscht, dafür reicht kein Bärenfell;


    da waren allen ernstes Diskussionen,

    - die Geolocation des Clients

    - die Ausstattung (Auflsg. und Bits/Pixel) des Clients

    in den HTTP-Request-Header zu packen ...;(


    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Mal so ne dämliche Frage, muss ich nginx neu kompilieren, wenn ich openssl 1.1.1 installiert habe? Manche Seiten sagen ja, manche nein.

    Unter Buster nicht. Einfach OpenSSL (und libssl1.1) aus Experimental installieren, TLS1.3 in ssl_protocols aufnehmen und das Ding neustarten. Das ist alles, danach läuft es. Es ist halt experimentell, nichts für den Produktiveinsatz.


    Vorsicht: OpenSSL 1.1 unterstützt in Debian derzeit per Default nur noch TLS >= 1.2! Wenn Du ältere Versionen brauchst, musst Du Deine openssl.cnf anpassen: https://lists.debian.org/debia…nce/2018/05/msg00000.html


    Dual RSA/ECDSA funktioniert übrigens auch bei Nginx einwandfrei. Dort reicht es, wenn man die cert/key Konfiguration fürs zweite Schlüssel/Chain Paar dupliziert.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    3 Mal editiert, zuletzt von KB19 ()

  • florian2833z Bei einem stabilen Debian Release würde ich lieber nicht an grundlegenden Dingen wie OpenSSL herumpfuschen. Das kann, fast wie mit der libc, schnell ins Auge gehen.


    Die genauen Parameter habe ich gerade nicht. Schau mal in die Source-Pakete bei Debian und vergleiche den debian-Ordner zwischen den Versionen. Was OpenSSL angeht, stecke ich zu wenig drinnen, um das beurteilen zu können.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Zurück zu Testing – bye, bye Experimental 8)

    Code
    # apt-get install openssl=1.1.0h-4 libssl1.1=1.1.0h-4 
    Paketlisten werden gelesen... Fertig
    Abhängigkeitsbaum wird aufgebaut.       
    Statusinformationen werden eingelesen.... Fertig
    Die folgenden Pakete werden durch eine ÄLTERE VERSION ERSETZT (Downgrade):
      libssl1.1 openssl
    0 aktualisiert, 0 neu installiert, 2 durch eine ältere Version ersetzt, 0 zu entfernen und 0 nicht aktualisiert.

    Ich hoffe, dass OpenSSL 1.1.1 bald offiziell erscheint und dann schnell den Weg nach Buster findet. Wäre schade, wenn es erst in Bullseye enthalten wäre.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)