Das längste Thema

    Das Paper "Is HTTP/2 More Energy Efficient Than HTTP/1.1 for Mobile Users?" ist echt interessant, hier mal ein Direktlinkals PDF zum lesen:

    https://pdfs.semanticscholar.o…8fcaba96ee9308ebed7b1.pdf


    Auch zum Thema CPU Last sind hier ein paar interessante Dinge die ich selbst nicht wusste:

    https://medium.com/@DarkDrag0n…nd-bandwidth-10dbb8458feb

    "Upgrading from HTTP/1.1 with encryption to HTTP/2 with encryption will reduce both CPU usage and bandwidth of your server."


    Ich glaub ich muss meine mini vServer alle auf HTTP/2 umstellen und HTTP/1.1 komplett deaktivieren^^

    Zitat von Gunah

    HAMMER

    Zitat von Dragon

    Naja, SNI kann doch mittlerweile als Standard angenommen werden. Alternativ gibt es aber auch noch Multi-Domain-Zertifikate.

    meinst Du so ein Zertifikat, wie das von hier: https://support12.cdnetworks.net/

    (sehr vertrauenserweckend)


    Na ja, wenn man die iDinger betrachtet ja, aber Dank Markfragmentierung am Android-Sektor sieht die Welt etwas anders aus;

    und auch bei den sonstigen Teilnehmern;

    vmk deine Links sind ja ok, aber rücken hier etwas ins Rampenlicht, was so nicht stimmt; klar die neusten Releases der

    am Markt befindlichen Browser und anderer Agents/Clients können SNI, aber nicht überall sind diese im Einsatz;


    denke nur an die Geschichte zurück, wie lange dauerte es bis tatsächlich verbleites Benzin von den Zapfsäulen tatsächlich überall verschwand;

    mit der Einführung des unverbleiten Benzins konnten ja auch alle Neuwagen damit umgehen - genau das sagt der eine Link aus - aber die tatsächlich

    verwendeten waren noch länger nicht in der Lage - das meinte ich;


    und der andere Link zum Thema HTTP/2 scheint auch etwas mißglückt zu sein, ich meinte auch hier

    HTTP/1.1 vs. HTTP/2 over TLS, zumal es f. HTTP./2 ohne TLS client-/browserseitig keinen Support gibt;


    Nachtrag: es wäre ja absurd zu denken, daß f. Verschlüsselung keine zusätzlichen Resourcen notwendig wären;

    von daher vmk braucht es auch keine Links;

    Grüße / Greetings

    Walter H.


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

    Die Seite ist auch ganz witzig: http://www.httpvshttps.com/ (Am besten mal mit simuliertem slow 3g probieren, dann sieht man, wo http/2 besonders viel bringt, nämlich bei mobilen Geräten mit schlechter Anbindung)


    Wobei man natürlich bei Verwendung von http/1.1 das ganze noch etwas optimieren könnte, z. B. mittels css-sprites


    Aber letztlich ist das ganze Bundling, was mit http/1.1. noch Best Practice war, ziemlich unnötig mit http/2 und eher ein Anti-Pattern, da man durch das Bundle ja evtl. gleich mehr lädt als der Browser für die eigentliche Seite zur Darstellung benötigt.

    EDIT: Der Artikel analysiert, wie viel Performance Einbrüche man beim Einsatz von https gegenüber http hat: https://www.keycdn.com/blog/https-performance-overhead/


    Ich habe auch mal gedacht, dass https viel Leistung fressen würde, aber das ist einfach nicht der Fall. Seit man sich kostenlose Zertifikate von let's encrypt holen kann, spricht meiner Meinung nach nichts mehr gegen https


    Wo siehst du einen flächendeckenden Einsatz von Browsern und Betriebssystemen die seit 7 Jahren keinerlei Updates erhalten haben? Welche Gruppe von Endanwendern siehst du in dieser Kombination im Internet unterwegs?


    Zum Nachtrag: Das behauptet hier niemand. Du verdrehst hier mit voller Absicht die Fakten. Hast du dir überhaupt einen der Links in diesem Thread angeschaut?

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

    Zitat von vmk

    Zum Nachtrag: Das behauptet hier niemand. Du verdrehst hier mit voller Absicht die Fakten. Hast du dir überhaupt einen der Links in diesem Thread angeschaut?

    Here we go again ^^


    Ich zitiere mal noch aus dem verlinkten Artikel von mir:

    "The CPU usage probably also benefits from HTTP/2 being binary protocols which explains why HTTP/2’s (with encryption) CPU usage is slightly lower than HTTP/1.1 without encryption."


    Also laut dem Benchmark (Details im Link oben) ist HTTP2 selbst mit Verschlüsselung sparsamer was "CPU" angeht auf Seite des Servers. Klar Verschlüsselung braucht CPU-Leistung, aber der Vorteil in der Effizienz des Protokolls ist größer wie der zusätzliche Verschlüsselungsaufwand laut diesem Test, was unterm Strich die CPU entlastet. 8) Davon ab verursacht TLS keinen all zu großen Overhead, dank CPU-Features etc. Ich gebe zu, der Test oben ist nur von einer "unbedeutenden Person", daher hier noch ein paar Links von größeren Organisationen die massenhaft Traffic bewältigen müssen ;)


    https://www.keycdn.com/blog/https-performance-overhead/


    Zitat

    "If you are running on HTTP/2 (HTTPS) this only requires a single connection per origin which means few sockets, memory buffers as well as TLS handshakes. Because of this it you might be able to handle more users with fewer resources as opposed to HTTP"


    "In January 2010, Gmail switched to using HTTPS for everything by default. They didn’t deploy any additional machines or special hardware and on their frontend machines, SSL/TLS accounted for less than 1% of the CPU load."


    "Many people believe that SSL/TLS takes a lot of CPU time and we hope the preceding numbers will help to dispel that." – Adam Langley, Google


    Hier noch ein älterer Test von 2013 (!) mit SPDY im Vergleich zu HTTP und HTTPS, auch hier ist bis auf einen minimal größeren CPU overhead SPDY mit TLS effizenter wie HTTP:

    https://www.neotys.com/blog/pe…spdy-enabled-web-servers/


    Zitat

    It turns out that SPDY also has advantages on the server side:

    • Compared to HTTPS, SPDY requests consume less resources (CPU and memory) on the server.
    • Compared to HTTP, SPDY requests consume less memory but a bit more CPU. This may be good, bad, or irrelevant depending on which resource (if either) is currently limiting your server.
    • Compared to HTTP/S, SPDY requires fewer Apache worker threads, which increases server capacity. As a result, the server may attract more SPDY traffic

    From these results, it is clear that Apache tuning performed for HTTP/S may not be appropriate after SPDY is enabled on the server.

    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.

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

    Das ganze Gerede von DNS, HTTP/2, SSL, ... sagt mal, wie haltet ihr das mit euren Zertifikaten?


    Da ich gerade eh dabei bin, vom certbot auf acme.sh umzusteigen, kam die Frage auf, ob es bei der Zertifizierung via DNS nicht sogar Sinn macht, die Zertifikate zentral über einen Server zu verwalten und dann quasi an die anderen Server zu verteilen. Scheinen ja einige hier so zu machen.


    Stellt sich nur die Frage, ob Pull oder Push, via SSH oder SFTP?


    Lasst mal hören!

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

    Die Zertifikate laufen bei mir alle über pfsense. Dort werden per API pauschal Wildcard Zertifikate ausgestellt.

    Die Verteilung erfolgt auf zwei Arten: Direkt innerhalb der pfsense in den haproxy. Alternativ per cronjob an die Clients mit einem service reload.


    Das Monitoring erfolgt per Zabbix.

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

    Zitat von vmk

    Die Zertifikate laufen bei mir alle über pfsense. Dort werden per API pauschal Wildcard Zertifikate ausgestellt.

    Die Verteilung erfolgt auf zwei Arten: Direkt innerhalb der pfsense in den haproxy. Alternativ per cronjob an die Clients mit einem service reload.


    Das Monitoring erfolgt per Zabbix.

    Klingt erst mal ganz interessant! Muss nur genau gucken, ob und in wie weit die Anbieter DNS Settings per API zulassen.


    Zumindest Netcup und Aliyun sollten kein Problem sein, hier liegen auch die meisten Domains. HE hat sowas glaube ich nicht o0

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

    Zitat von vmk

    Wo siehst du einen flächendeckenden Einsatz von Browsern und Betriebssystemen die seit 7 Jahren keinerlei Updates erhalten haben?

    davon spricht keiner; daher mal der umgekehrte Ansatz:


    HTTP/2 setzt zwingend TLS voraus, weil es sonst keinen Support durch diverse Browser/Clients gibt

    (ich will jetzt nicht hören, daß man das ja auch ohne TLS supporten kann, ja man kann, ist aber nicht);


    und unter folgendem was völlig ignoriert wurde

    Zitat von mainziman

    - erschwerte bzw. unmögliche Unterscheidung zwischen wichtig/unwichtig bzw. kritisch/unkritisch f. Otto-Normaluser,

    wenn es denn mal seltsame Fehler liefert ob man es denn umgehen kann/darf;

    auch mit dem Hintergedanken daß nicht überall derart seltsame Multi-Domain-Zertifikate wie das von z.B. https://support12.cdnetworks.net/

    verwendet werden sollen, noch SNI überall zum Einsatz kommen kann;

    (auch will ich hier jetzt nicht hören, was man ändern kann, daß man dennoch derartige Unfugzertifikate oder SNI verwenden kann,

    ist bei der Betrachtung kein Thema)

    ist es dennoch möglich auf HTTP/1.1 over TLS only umzustellen,

    ohne daß sich das Verhalten wie hier:

    KazakhtelecomJSCnotifiesNationalsecuritycertificate.png

    seien es auch nur MITM Boxen in Unternehmen, inflationär vermehrt?


    Wer das mit ruhigem Gewissen mit einem uneingeschränkten 'Ja' beantworten kann,

    dann Gute Nacht; ich kann es definitiv NICHT;


    ein uneingeschränktes 'Ja' hier ist notwendige Voraussetzung f. HTTP/2


    Grüße / Greetings

    Walter H.


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

    Würde das Ganze nun via


    scp -i ~/.ssh/id_rsa -P <port> /pfad/zu/cert.xyz root@server.de:/etc/ssl/domain


    gestalten, oder ist das ne schlechte idee? der verteilende Server logt sich quasi ein und überträgt die jeweiligen certifikate.


    oder doch lieber rsync bei mehreren files *grübel*

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

    geekmonkey ob rsync od. scp ist nur eine Frage des Geschmalcks;


    wenn Du dies zentralisierst, denke evtl. daran, daß diese zentrale Einheit besonders geschützt vor Zugriffe durch 3rdparty werden muss;

    eine eigene VM, welche auch bei Dir zu Hause laufen kann, würde sich f. diesen Zweck besonders gut eignen, und genau dann wenn

    die Zerts. erneuert werden müssen wird diese VM angeworfen und der "Job" erledigt, und die restliche Zeit ist diese abgedreht;

    Grüße / Greetings

    Walter H.


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

    Zitat von mainziman

    geekmonkey ob rsync od. scp ist nur eine Frage des Geschmalcks;


    wenn Du dies zentralisierst, denke evtl. daran, daß diese zentrale Einheit besonders geschützt vor Zugriffe durch 3rdparty werden muss;

    eine eigene VM, welche auch bei Dir zu Hause laufen kann, würde sich f. diesen Zweck besonders gut eignen, und genau dann wenn

    die Zerts. erneuert werden müssen wird diese VM angeworfen und der "Job" erledigt, und die restliche Zeit ist diese abgedreht;

    Wäre ne Option! Danke für den Tipp! Muss mir mal überlegen wie genau ich das mache. Muss halt auch noch auf einer der Maschinen ne Hand voll Container neu starten, da gerade Mailcow einige der Zertifikate benötigt. Also zusätzlich zur Datenübertragung noch nen script, ...


    Das Übertragen lässt sich ja relativ easy automatisieren hab ich gerade gesehen:


    Code
    acme_dir="/etc/acme/mycerts"
remote_dir="/etc/ssl/private"
remote_host="$1"
domain="$2"

scp -i ~/.ssh/id_rsa -P <port> ${acme_dir}/${domain}/${domain}.cer ${acme_dir}/${domain}/${domain}.key root@${remote_host}:${remote_dir}/${domain}

    bissel viele variablen, aber so bleibts dynamisch - haha.


    mit ./script server.de domain.de lassen sich so zumindest in nem einzeiler die Zertifikate via cron oder post-hook verschieben :)

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

    Zitat von geekmonkey

    Das ganze Gerede von DNS, HTTP/2, SSL, ... sagt mal, wie haltet ihr das mit euren Zertifikaten?

    Zertifikate für reine HTTP Dienste werden von Cloudflare generiert und die Requests dann über meinen nginx-Proxy an den dahinter liegenden LXD Container getunnelt (intern ohne valides Zert.). Container die selbst Dienste bereitstellen (E-Mail, Mumble) generieren sich die Zertifikate über acme.sh mit DNS-Challenge selbst.

    Zitat von janxb

    Zertifikate für reine HTTP Dienste werden von Cloudflare generiert und die Requests dann über meinen nginx-Proxy an den dahinter liegenden LXD Container getunnelt (intern ohne valides Zert.). Container die selbst Dienste bereitstellen (E-Mail, Mumble) generieren sich die Zertifikate über acme.sh mit DNS-Challenge selbst.

    Ja, theoretisch könnte auch jeder Server für die jeweiligen Domains selbst die Zertifikate generieren. Dachte halt eine Zentrale Anlaufstelle ist vielleicht einfacher, gerade wenn man mal nen anderen Server neu aufsetzt.


    Klar sollte die Kiste gut abgesichert sein, aber ich meine, was macht das groß für einen Unterschied, ob ich die Zertifikate lokal auf dem Server habe, oder sie remote per scp übertrage? So oder so hätte ein Angreifer bei erfolgreichen Einbruch Zugriff auf die Files.


    Ist ja nicht so als wenn ich hunderte Wildcard Zertifikate irgendwo lagern will- haha. Geht in der Summe um vielleicht 30 Domains, wovon 20 fast ausschließlich privat und eher sinnlos sind ?


    Klar hätte der Angreifer dann Zugriff auf die anderen Server, aber Wenn er auf den einen kommt, warum nicht auf alle ??

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...