Posts by gunnarh

    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.

    genau so sammelt man dann so richtig Daten, das müßte wenn schon eine Domain mit seriösem WHOIS oder eine fbi.gov Domain sein ...

    Das die Domain kein sinnvolles whois hat liegt daran, dass .com Domains seit geraumer Zeit keines mehr haben.

    Wem die Site gehört ist unmittelbar erkennbar und ohnehin allgemein bekannt - Troy Hunt (https://twitter.com/troyhunt)


    Seine Services (man kann nicht nur interaktiv auf der Website prüfen, sondern es gibt eine umfangreiche API) werden von zahlreichen großen Portalen genutzt um z.B. bei der Registrierung eines neuen Benutzerkontos keine bereits als kompromittiert bekannten Credentials zuzulassen. Dabei werden übrigens keine Passwörter zum Anbieter gesendet, sondern nur Hashes die (im Falle der Website noch auf Client-Seite per Javascript generiert werden) geprüft.


    Fazit: Vertrauenswürdig

    Würden Sie sich überlegen, ob es möglich ist, die Verwendung der "E-Mail-Adresse Vertragspartner" zu splitten.


    Dieser Wunsch wurde (in noch etwas erweiterterer Form) vor einem halben Jahr bereits diskutiert und auch seitens Netcup positiv kommentiert, siehe hier:

    https://forum.netcup.de/netcup…mail-adresse-n/#post98839


    Auch ich würde es gerne sehen, wenn die Umsetzung gemäß diesem Post von damals erfolgen würde.

    Ja, das sind Crawler von SearchEngines etc... und Bots. Aber das müssen nicht zwangsweise Bots sein, die böses im Schilde führen.

    Es gibt diverse Projekte auch von WhiteHats, Researchern etc... die alle Domains, alle Hostnamen aus ausgestellten Zertifikaten (über das Transparency-Programm wird das live publiziert!) bzw. den kompletten IPv4 Space abgrasen und Daten erheben, z.B.:

    • Statistische Daten zur eingesetzten Serversoftware(version)
    • SSL/TLS/StartTLS-Handshake, Verwendete Cipher-Suiten und Versionen etc...
    • Verwendete Zertifikate
    • u.v.m....

    Daraus lassen sich auch in der Welt der WhiteHats interessante Trends/Statistiken erstellen.

    Man muss sich einfach damit abfinden, dass man schon wenige Sekunden nachdem man mit einer VM oder einem WebAuftritt online geht zahlreiche Requests auf allen möglichen Ports (SMTP, SSH, HTTP, HTTPS, ...) erhält (mit guter, aber auch in böser Absicht).

    mainziman danke für den Hinweis, habe nicht bemerkt das Du nicht der OP bist.


    für ipv6help.de sind die TLSA Records inzwischen bei allen 3 authoritativen Servern korrekt abrufbar und auch https://dane.sys4.de/smtp/ipv6help.de meldet alles OK.


    Was die Beobachtung "Resolver von Netcup liefern die TLSA-Records noch nicht" angeht folgende Mutmaßung:

    • Du hast am vServer mit den NetCup-Resolvern testweise schon vor Erstellung der TLSA-Records diese abzurufen versucht, dort ist daher ein NXDOMAIN gecacht worden und dieses Caching bleibt auch noch gemäß Deiner Zone-Konfiguration auch noch 8 Stunden erhalten.
    • Am Gerät zuhause mit den Resolvern deines ISP hast Du vermutlich erst geprüft als die TLSA-Records bereits eingetragen waren, der Erstversuch konnte daher nichts gecachtes liefern sondern hat bei den authoritativen Servern nachgefragt und eine Antwort erhalten, die nun für 8 Stunden gecacht ist.

    Nochmals bezugnehmend auf die Wildcard-Frage: Ja, das *.ipv6help.de Zertifikat das Du aktuell unter https://mx01.ipv6help.de/ verwendest kannst Du auch für Deinen Mailserver verwenden. In Bezug auf DANE/TLSA sowieso, aber auch in Bezug auf einfache STARTTLS-SMTP MTA zu MTA Kommunikation ohne DANE.

    Der Hinweis betreffend "48 Stunden warten" betrifft nur externe Resolver. Die authoritativen Nameserver der Domain müssen die Änderung sofort bereitstellen - sie tun es jetzt um 11:30 geprüft jedoch nicht, somit liegt kein "du musst warten" Problem vor sondern die Einträge sind schlicht nicht vorhanden.


    Deine TLSA Records für ipv6help.de - sind nicht vorhanden, zum Vergleich auch die korrekte Ausgabe meiner hitco.at Domain:

    Code
    1. root@nc:~# dig +short _25._tcp.mx01.ipv6help.de TLSA @third-dns.netcup.net
    2. root@nc:~# dig +short _25._tcp.mx01.ipv6help.de TLSA @second-dns.netcup.net
    3. root@nc:~# dig +short _25._tcp.mx01.ipv6help.de TLSA @root-dns.netcup.net
    4. root@nc:~# dig +short _25._tcp.nc.hitco.at TLSA @localhost
    5. 2 1 1 60B87575447DCBA2A36B7D11AC09FB24A9DB406FEE12D2CC90180517 616E8A18
    6. 3 1 1 CD54CE5770B29860600F1E7CE3368352975C01E39BC55C46AF4A32B7 73D209B5
    7. root@nc:~# dig +short _25._tcp.nc.hitco.at TLSA @ncs.hitco.at
    8. 3 1 1 CD54CE5770B29860600F1E7CE3368352975C01E39BC55C46AF4A32B7 73D209B5
    9. 2 1 1 60B87575447DCBA2A36B7D11AC09FB24A9DB406FEE12D2CC90180517 616E8A18

    Zur Frage "Wildcard-Zertifikat": Mit TLSA pinnst Du je nach verwendetem Selector einen Zertifikats-Fingerprint oder einen PublicKey-Fingerprint. Ich würde dir empfehlen den PublicKey-Fingerprint zu verwenden, dann kannst Du nämlich unter Verwendung eines gleichbleibenden CSR bei LetsEncrypt neue Zertifikate anfordern ohne jedes mal den TLSA-Eintrag ändern zu müssen. Wie der Antragsteller oder SubjectAlternativeName Eintrag im Zertifikat selbst lautet ist für TLSA/DANE egal, der kann auch völlig unpassend sein.


    Ausführliches HowTo: https://hitco.at/blog/sicherer…ste-anbieter-dnssec-dane/
    Sowie Hinweis betreffend CSR/LetsEncrypt: https://hitco.at/blog/lets-encrypt-csr/