Posts by gunnarh

    Netcup bietet keine automatischen Backups.

    Sich Backups mittels kostenpflichtiger Snapshots die man automatisiert erstellt und runterlädt zu basteln wäre zwar denkbar, aber ich würde sagen es gibt zweckmäßigere Lösungen. Um diesbezüglich zu beraten müsste man aber zuerst einmal wissen was am Server betrieben wird und welche Daten konkret in welcher Menge und Änderungshäufigkeit zu sichern sind. Kleine Datenbanken werden oftmals mittels automatisierter SQL-Dumps gesichert. Content von Mail- und Webservern mittels rsync oder duplicity. Ganze Betriebssystem-BareMetal-Images lassen sich z.B. mit Veeam anfertigen.

    Ja, allerdings solltest Du einen praktischen UseCase haben.

    Üblicherweise verwendet man den Download des SnapShot (=das hier diskutierte "Backup") um diesen auf einer anderen Maschine einzuspielen.

    Für klassisches periodisches (z.B. tägliches, wöchentliches) Backup eignet sich dies kaum.

    Das Let's Encrypt Validierungssystem nutzt keine vachenden Resolver sondern fragt immer die authoritativen Nameserver der Domain ab. Allfällige Bedenken das man ja erst warten müsse bis irgendwelche Resolver ihre Caches verwerfen sind daher unangebracht. Sobald die authoritativen Nameserver den Record liefern (was bei einem typischen Master-Slave Setup nach wenigen Sekunden sein sollte) kann somit die Validierung erfolgen.

    Für Wildcard-Zertifikate ist bei Let's Encrypt derzeit ausschließlich eine DNS-Challenge zulässig.

    Die HTTP-Challenge kann nur für reguläre Non-Wildcard (Multi-)Domain Zertifikate verwendet werden.


    1. Warum muss es unbedingt ein Wildcard-Zertifikat sein?

    2. Warum kannst Du den Nameserver nicht wechseln, dazu ist ja in der Regel kein Registrar-Wechseln nötig.

    Ein Verstoß gegen die Preisauszeichnung ist - wie korrekt bereits darauf hingewiesen - unlauterer Wettbewerb.

    Das heißt aber nicht, dass der Kaufinteressent zu diesem Preis bedient werden muss, diesen Preis einklagen kann oder anderweitige Rechtsansprüche für den Kaufinteressenten daraus erwachsen. Vielmehr können Verbraucherschutzverbände und/oder der Mitbewerb dagegen (am Rechtsweg) vorgehen. Der Kaufinteressent selbst hat aber unmittelbar kein Rechtsmittel in der Hand.


    Jedenfalls ist das so in Österreich, und scheint auch bei unseren westlichen Lieblingsnachbarn nicht anders zu sein.

    Vielleicht findet sich ja jemand, der Dir ein

    openssl speed -evp aes-128-cbc aes-256-cbc

    auf einer VPS 200 G8 ausführt.


    Auf meinem Single-Core VPS 500 G7:

    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes

    aes-256 cbc      45745.25k    47066.40k    48423.21k   117738.70k   120622.84k

    aes-128-cbc     392572.91k   425643.32k   434176.34k   438758.92k   438758.57k

    Ich kann zu OpenVPN keine Angaben machen - aber zum Vergleich:

    Ich habe zwei VMs mittels nativem Kernel-IPSEC im ESP-Transport-Mode unter Verwendung von StrongSWAN verbunden.


    Ich erreiche 560MBit konstant, geprüft mit iperf.

    Die VM ist ein Single-Core VPS 500 G7, das AES CPU Flag der vCPU ist sichtbar, die vCPU meint sie läuft mit 2GHz.


    Ob ein aktueller VPS 200 G8 die gleichen Werte erreichen würde kann ich Dir nicht sagen, aber gefühlsmäßig denke ich schon, dass sich 200MBit ausgehen sollten.

    können bei der Validierung der Zertifikatskette verwendet werden, obwohl sie es nicht dürften, wenn der Server nur das End-Zertifikat mitschickt;


    Aus diesem Verhalten des Browsers ergibt sich noch kein unmittelbares Security-Problem. Wenn mit dem gecachten (fehlenden) Intermediate-Zertifikat die Chain geprüft werden kann, und keines der Zertifikate zurückgezogen wurde, dann ist die Chain valide - auch wenn der Webserver fehlerhaft konfiguriert ist. Ich bleibe bei meiner Einschätzung: Ja, das ist eine Fehlkonfiguration des Servers. Daraus resultiert aber kein Security-Problem, sondern nur ein Funktionsproblem der Website bei jenen Browsern / Anwendern die das Intermediate-Zertifikat nicht kennen.

    Kann mit diesen Aussagen ad-hoc wenig anfangen


    primes.utm.edu liefert sowohl das Leaf-Zertifikat *.utm.edu als auch das Internediate-Zertifikat "Go Daddy Secure Certificate Authority - G2", das Stammzertifikat "Go Daddy Root Certificate Authority - G2" befindet sich in den RootCA-Stores von Firefox und Windows. Um ein Let's Encrypt Zertifikat handelt es sich nicht, die Chain ist auch intakt.


    pdfencrypt.com bietet gar keinen Dienst auf tcp/443 HTTPS an.


    Die Theorie der "Sicherheitslücke" bei nicht mitgesendetem Intermediate-Zertifikat kann ich nicht nachvollziehen. Worin soll diese bestehen? Wenn die Chain nicht validiert werden kann, liefern alle Browser eine Warnung - ein Websiteanbieter der die Chain nicht korrekt mitsendet hat daher ein Problem der problemlosen Erreichbarkeit, aber nicht unmittelbar ein Security-Problem.

    Ob man tatsächlich die Zertifikate zum Let's Encrypt Account zuordnen kann weiß ich auch nicht - ich wüsste ad-hoc nicht wie man dies über Certificate-Transparency tun könnte. Aber das ist auch wie von killerbees19 erläutert gar nicht nötig. Sich mehrere Let's Encrypt Accounts anzulegen schützt vor einer Daten-Aggregation jedenfalls nicht.


    Nochmals zur Verdeutlichung - Diese "Info-Dienste" gehen wie folgt vor:

    1. Sie monitoren öffentliche Quellen wie die Logs von TLDs und die bereits angesprochenen Certificate-Transparency Logs. Damit erhalten Sie zeitnahe Infos zu vielen neu registrierten Domainnamen und zu so gut wie allen neu ausgestellten Zertifikaten (inklusive aller SubjectAlternativeNames in den Zertifikaten).

    2. Nun macht man einfach für all diese Namen ein DNS-Lookup und erhält so die IPv4 und IPv6 Adressen

    3. In einer Datenbank abgelegt kann mit dieser Daten nun ganz einfach verknüpft werden, welche "Domains" unter der gleichen IP-Adresse gehostet werden


    Du kannst dagegen nichts tun, außer - wie bereits erläutert - unter einer IP-Adresse nur einen WebAuftritt bereitstellen, in Zeiten von IPv4-Knappheit aber vermutlich ein teures und außerdem völlig unnötiges Unterfangen.


    Die Aussage diese Dienste würden "jeden vHost" kennen ist aber jedenfalls nicht korrekt, sie kennen nur jene vHosts die sie aus irgend welchen Quellen "crawlen" können. Der WebServer gibt diese jedenfalls nicht einfach so preis. Wenn du z.B. nicht möchtest, dass öffentlich erkennbar ist das Du auch den vHost "meingeheimesforum.meinedomain.tld" betreibst, dann kannst Du z.B. ein *.meinedomain.tld Wildcard-Zertifikat beziehen um so einem Aufscheinen im Transparency-Log mit "meingeheimesforum.meinedomain.tld" zu entgehen. Aber bedenke: Security die auf Geheimhaltung von eigentlich öffentlichen Informationen beruht funktioniert ohnehin nicht.


    Noch ein Hinweis: Bei DNSSEC signierten Domains kann über Zone Walking ganz einfach eine vollständige Liste aller DNS-Records enumeriert werden, Abhilfe bietet hier die Verwendung von NSEC3.

    Wer Let's Encrypt noch mit TLS-SNI-01 Validation benutzt (das betrifft z.B. den "alten" CertBot der in Ubuntu 16.04 standardmäßig enthalten ist) der sollte folgenden Hinweis beachten: Let's Encrypt: February 13, 2019: End-of-Life for All TLS-SNI-01 Validation Support


    Einen neueren CertBot bekommt man, indem man z.B. dieses Repo hier nutzt: https://launchpad.net/~certbot/+archive/ubuntu/certbot


    Habe meine Scripte nun alle auf --authenticator webroot --webroot-path /var/www/... umgestellt.

    Egal wofür man sich entscheidet, ich kann empfehlen die Doku nicht am Server selbst sondern wo anders zu hosten.

    Genau dann wenn etwas nicht funktioniert und man diese daher braucht, ist sie dann vielleicht nämlich nicht oder schlecht zugreifbar.


    Aus meiner Erfahrung ist das konkrete Produkt auch nicht so wichtig, viel wichtiger ist die eigene Disziplin. Wer keine sensiblen Informationen in die Doku schreibt kann auch einfach ein Google-Docs Dokument verwenden, da ist die Historie auch wunderhübsch per Zeitleiste nachvollziehbar und der WYSIWYG Editor für diese Zwecke mehr als ausreichend.

    wie finanziert sich das?

    CmdrXay hat bereits auf die Spenden hingewiesen.

    Dazu kommt noch, dass der Typ derartig berühmt ist und jede Woche auf großen Konferenzen Vorträge hält, dass sich die Firmen bei ihm in der Schlange anstellen und fragen ob Sie ihm nicht was sponsern dürfen. Er zahlt weder für die Azure-Services noch für die Cloudflare-Services (siehe dazu auch sein Blog wo er beschreibt wie das gebaut ist und skaliert) - die Anbieter drängen sich ihm auf ihn gratis hosten zu dürfen, wenn er sie nur als Dank in seinen Vorträgen und im Blog erwähnt.