Das längste Thema

Quote from Track1991

Das sagt sehr viel über die Kompetenz der Reporter

Das wurde nicht von Reportern geschrieben, sondern von der Heidorn GmbH - https://www.heidorn.gmbh/

Danke für deine Info.

Sie haben sich ja schon Mühe gegeben, uns Laien das Webhosting näherzubringen. An manchen Stellen konnte ich mir das Lachen nicht verkneifen.

Besonders der Abschnitt "Was ist Webhosting und wozu benötigt man es?" hat schon was.

An die Krypto-Profis hier

Was nehm ich da am besten für ECDSA?

Größere Bitlänge = besser ist mir klar. Mir gehts primär um die "Arten"

pasted-from-clipboard.png

Einsatzzweck ist https und Server <=> Server (Datenbank <=> PHP etc.)

Bevor ich nun alle Namen google weiß eventuell jemand spontan die Antwort

Danke!

Sehr interessant:

https://www.heise.de/newsticker/mel…ge-4710642.html

und als Video-Tip aus den Kommentaren von heise dazu:

Hänge gerade bei dem ersten Video

Aufreger des Tages: https://orf.at/stories/3163480/

Quote from peng

An die Krypto-Profis hier

Was nehm ich da am besten für ECDSA?

Größere Bitlänge = besser ist mir klar. Mir gehts primär um die "Arten"

pasted-from-clipboard.png

Einsatzzweck ist https und Server <=> Server (Datenbank <=> PHP etc.)

Bevor ich nun alle Namen google weiß eventuell jemand spontan die Antwort

Danke!

Display More

Profi jetzt nicht, aber ich habe mir glaube beim Kuketz mal folgendes gemopst:

root@reverseproxy:~# cat /etc/nginx/conf.d/subconfig/ssl_configuration.conf
# standard SSL config
ssl_protocols                   TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers       on;
ssl_ciphers                     ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256;

ssl_dhparam                     /etc/nginx/dhparams/dhparams.pem;
ssl_ecdh_curve                  secp521r1:secp384r1:prime256v1;

ssl_session_timeout             1d;
ssl_session_cache               shared:SSL:50m;
ssl_session_tickets             off;

ssl_stapling                    on;
ssl_stapling_verify             on;

resolver                        [fd00:21:1::103] valid=300s;

root@reverseproxy:~#

Läuft auf mehreren Servern recht gut... Würde mal behaupten, damit kann man arbeiten.

Quote from peng

Was nehm ich da am besten für ECDSA?

Definiere "am besten"?

Das lässt sich imho nicht pauschal beantworten. Manche ciphers sind schneller als andere, für manche gibt es Hardwareunterstützung, manche sind sicherer als andere. (Fast) alle haben ihre Daseinsberechtigung. Aber wenn du nur TLS1.3 einsetzt, dann sind (Stand heute) alle verfügbaren "sicher".

Da Krypto ein schwieriges Thema ist halte ich mich bei meinen Konfigurationen an die Experten von: ssl-config.mozilla.org

Quote from eripek

Aufreger des Tages: https://orf.at/stories/3163480/

ja Teletext Seite 102 brachte die Kurzfassung

ORF-Teletext-Seite102.png

Quote from peng

Was nehm ich da am besten für ECDSA?

Linktip: https://wiki.mozilla.org/Security/Server_Side_TLS (passend zu der von Steini erwähnten Seite). Überprüfung kann dann via https://www.hardenize.com/ oder https://www.ssllabs.com/ssltest/ erfolgen. Theoretische Grundlagen finden sich beispielsweise hier: https://crypto.stackexchange.com/q/18787.

Quote from Track1991

Zoom Webinar- Die vor kurzen wieder gehackt worden sind, sehr guter Anbieter wenn man ein Datenklo braucht

Diese Aussage ist nicht korrekt. Es gab in dieser Angelegenheit keine Sicherheitslücke bei Zoom. es wurden bereits gestohlene Username-Passwort Kombinationen aus vorherigen Leaks bei anderen Anbietern massenweise bei Zoom ausprobiert, sogenanntes Credential Stuffing.

Quote from whoami0501

Profi jetzt nicht, aber ich habe mir glaube beim Kuketz mal folgendes gemopst:

Code

root@reverseproxy:~# cat /etc/nginx/conf.d/subconfig/ssl_configuration.conf
# standard SSL config
ssl_protocols                   TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers       on;
ssl_ciphers                     ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256;

ssl_dhparam                     /etc/nginx/dhparams/dhparams.pem;
ssl_ecdh_curve                  secp521r1:secp384r1:prime256v1;

ssl_session_timeout             1d;
ssl_session_cache               shared:SSL:50m;
ssl_session_tickets             off;

ssl_stapling                    on;
ssl_stapling_verify             on;

resolver                        [fd00:21:1::103] valid=300s;

root@reverseproxy:~#

Display More

Läuft auf mehreren Servern recht gut... Würde mal behaupten, damit kann man arbeiten.

Naja aber 50m für den ssl_session_cache sind sehr sehr großzügig, 10MB sind ungefähr 40000 SSL Sessions.

Seit vor einigen Monaten (Jahren?) eine neue tmux Version rauskam sind die Fenster > 9 nur über "M-Buchstabe" zu erreichen, mag mir jemand erklären was genau ich da drücken muß? Ich verwende seit über 10 Jahren tmux aber das hab ich noch nicht gehabt solch ein Problem.

Habe mich zwar an meine Workarrounds gewöhnt aber mal wieder eines der "hinteren" Fenster direkt adressieren wäre schon edel.

tmux.png

Quote from peng

Was nehm ich da am besten für ECDSA?

Größere Bitlänge = besser ist mir klar. Mir gehts primär um die "Arten"

hier vlt. darauf achten, welche denn unterstützt, nicht überall ist jede "Art" unterstützt;

musste ich soeben auch bei Let's Encrypt feststellen ...

Quote from mainziman

ja Teletext Seite 102 brachte die Kurzfassung

Es regieren: Fear, uncertainty & doubt.

Quote from Bodenhaltung

Naja aber 50m für den ssl_session_cache sind sehr sehr großzügig, 10MB sind ungefähr 40000 SSL Sessions.

Ich glaube das war ich, da war ich wirklich großzügig. Könnte ich theoretisch mal kleiner machen. Aber warum eigentlich? An RAM mangelts eigentlich nicht...

Quote from mainziman

hier vlt. darauf achten, welche denn unterstützt, nicht überall ist jede "Art" unterstützt;

musste ich soeben auch bei Let's Encrypt feststellen ...

Lets Encrypt liefert maximal 384er ECDSA Zertifikate.

Meine Wenigkeit hat sich mal jenes Script dafür gebaut - kann man mit ./getCert.sh <Domain> aufrufen...

#!/bin/bash

if [[ $1 == '' ]]
then
  echo "Please give me a domain name!"
  exit 1
fi

DOMAIN=$1
DIR="/etc/acme_letsencrypt/${DOMAIN}"

[[ -d ${DIR} ]] || mkdir -p ${DIR}

~/.acme.sh/acme.sh \
--issue \
--domain ${DOMAIN} \
--ecc \
--keylength ec-384 \
--ocsp-must-staple \
--webroot /var/www/letsencrypt \
--always-force-new-domain-key \
--key-file              ${DIR}/privatekey.pem \
--ca-file               ${DIR}/ca.pem \
--cert-file             ${DIR}/cert.pem \
--fullchain-file        ${DIR}/fullchain.pem

if [[ $? -eq 0 ]]
then
  # Get chain for nginx
  sed -n '/-----END/,/-----END/p' ${DIR}/fullchain.pem | tail -n+2 > ${DIR}/chain.pem
  sleep 3

  # Initial OCSP Caching
  openssl ocsp -no_nonce -issuer ${DIR}/chain.pem -cert ${DIR}/cert.pem -respout ${DIR}/ocsp.der -url $(openssl x509 -noout -ocsp_uri -in ${DIR}/fullchain.pem)

  # Show folder with certs
  ls -Al ${DIR}
fi

Bodenhaltung M steht manchmal für Alt. Probier mal z.B. Alt + a

Quote from whoami0501

Bodenhaltung M steht manchmal für Alt. Probier mal z.B. Alt + a

Ja, das klappt in der "Übersicht" aber nicht im normalen Fenster wo die 1-9 über tmuxKey+0-9 erreicht werden können, dort dann tmuxKey+alt+A klappt leider nicht.

Welche Desktopumgebung nutzt ihr unter Linux? Ich will mal wieder was anderes als

Cinnamon ausprobieren

Quote from whoami0501

Lets Encrypt liefert maximal 384er ECDSA Zertifikate.

US-Exportbeschränkungen?

Quote from mfnalex

Welche Desktopumgebung nutzt ihr unter Linux? Ich will mal wieder was anderes als

Cinnamon ausprobieren

KDE