Mist verdammter! In meiner Sun Ultra 45 ist gerade die Grafikkarte abgefackelt :-/ Im Grunde dürfte ich mich nicht aufregen, denn das System ist von 2006. Also inzwischen 9 Jahre alt. Welches 9-Jahre alte System darf nicht mal einen Def. haben?
Ich stand also vor der Entscheidung die Workstation endgültig in Rente zu schicken oder mich noch einmal um einen neuen VGA zu kümmern. Puhh…
Es sind zwei UltraSPARC IIIi 1.6-GHz CPUs verbaut, 8GB Speicher und ein paar feine SAS Platten…. Zusammen mit der Grafikkarte ist es noch immer ein ganz passables Arbeitsgerät. Vor allem wenn ein Solaris darauf rennt! Natürlich gibt es kaum etwas, dass man nicht genauso (wenn nicht sogar besser) auf jeder anderen Kiste machen könnte. Aber die Maschine ist nun schon so lange bei mir und arbeitet so perfekt, ich hänge einfach an der Kiste.
Ich werde mir also mal so eine refurbished Karte „klicken“. Irgendwo habe ich etwas von 70€ gelesen. Ich glaube nicht, dass ich 70€ in ein 9Jahre altes System stecken. Ich muss bekloppt sein!!!
Kann mich jemand verstehen / mir Mut machen? ==> kernel-error@kernel-error.com
Es gibt bereits seit einigen Jahren die Möglichkeit, seinen GPG Key in die DNS Zone zu packen. Oder besser gesagt, man kann in der Zone einen Ort angeben, an welchem man seinen GPG-Key finden kann.
Dieses ermöglichte bisher einen einfachen Weg um anderen seinen Schlüssel zukommen zu lassen! Unabhängig von den Schlüsselservern und den dort „möglicherweise“ im Umlauf befindlichen ~fake~ Keys.
Inzwischen gibt es einen neuen Ansatz, welcher sich gerade auf dem Weg in ein RFC befindet. Dieser beschreibt, einen neuen Resource Record. Der RR beinhaltet dann direkt den kompletten Schlüssel. So lässt sich dieser noch einfacher und (DNSsec sei Dank) sicherer verteilen.
Nun habe ich meinen aktiven GPG Schlüssel als OPENGPGKEY Record in meine Bind Zone gepackt….
Die aktuelle Gültigkeitsprüfung anhand von CAs hat so ihre Lücken. So erscheint jedes Zertifikat als gültig und vertrauenswürdig, sofern es nur von einer CA unterzeichnet wurde, welcher der Client selbst vertraut.
Erschleiche ich mir also ein gültiges Zertifikat für eine Domain oder schiebe es dem Client als vertrauenswürdig unter, wird sich der Benutzer zwar sicher und geschützt fühlen, dennoch ist er es nicht.
Nun gibt es mehrere Ansätze um diese Situation zu verbessern. TLSA / DANE zusammen mit DNSsec, HSTS (Strict Transport Security) usw… Inzwischen bin ich auf fast alle eingegangen. Es fehlt aber noch ein, wie ich finde, wichtiger Vertreter. HPKP (Public Key Pinning). Daher soll es nun um HPKP gehen 🙂
Public Key Pinning verfolgt einen ähnlichen Ansatz, wie Strict Transport Security, erweitert diesen nur etwas. Strict Transport Security wird als HTTP-Header gesetzt und sorgt dafür, dass ein Client für den Ablauf einer, durch diesen Header, gesetzten Frist nur noch SSL/TLS gesicherte Verbindungen zu dieser Domain benutzen wird. Public Key Pinning sorgt nun zusätzlich dafür, dass der Client nur gewisse Zertifikate über einen bestimmten Zeitraum annimmt.
Sind beide Header gesetzt, baut der Client also nur noch gesicherte Verbindungen auf und akzeptiert nur noch bestimmte Zertifikate, für einen gewissen Zeitraum. Dieses bietet ebenfalls gewisse Lücken, dennoch hebt es die Sicherheit ein ganzes Stück an, denn es wird für einen Angreifer deutlich aufwendiger seine gefälschten Zertifikate ins Rennen zu bringen.
Wie funktioniert es nun genau? Im HPKP Header übermittelt der Webserver zwei base64 encodete SHA256-Hash Werte von den Public Keys zweier Zertifikate, sowie eine Ablaufzeit (und ggf. noch ein paar Optionen). Zwei Hash Werte aus einem einfachen Grund… Es kann ja passieren, dass man sein Zertifikat tauschen möchte/muss. Wäre hier nur der Hash eines Zertifikates „fest gepinnt“, würden alle Clients den Verbindungsaufbau mit dem neuen Zertifikat verweigern und dieses im schlimmsten Fall bis zum Ablauf der gesetzten Frist (in meinem Beispiel gleich 60 Tage). Aus diesem Grund nimmt man zwei! Das aktive Zertifikat, welches man ggf. direkt von der CA unterschreiben lässt und einsetzte, sowie ein Backup-Zertifikat, welches man vielleicht nur bis zum CSR vorbereitet und an einer anderen Stelle aufbewahrt. Nun könnte man direkt noch ein anderes Verfahren einsetzten oder ein anderes System um dieses Zertifikat zu erzeugen usw. usw… Wir halten also fest, Hash Werte von zwei Zertifikaten, wobei eines selbstverständlich das aktive ist.
Diese Hashwerte lassen sich nun mittels openssl über die keys, csr oder das fertige Zertifikat bauen. Ich nehme dafür gerne direkt die keys, da sich aus diesen alles weitere ergibt. Als Test, auf korrekte Hash Werte, kann man natürlich alle drei Wege nutzen. Dabei sollten sich natürlich immer die gleichen Werte ergeben!
Ich gehe also davon aus, dass bereits zwei Keys erstellt wurden. Damit lassen sich nun wie folgt die Hash Werte erstellen:
Um die Header setzten zu können muss beim Apache noch das Modul headers geladen werden:
$ a2enmod headers
In der eigentlichen Konfigurationsdatei des jeweiligen hosts/vhosts fehlt nun nur noch folgende Zeile:
Header always set Public-Key-Pins: 'max-age=5184000; pin-sha256="31XofAyJSqWKGO4xhVZFNe5+grAZQ4cvl2tahddU/ME="; pin-sha256="KJV9jpFftvj+TjzaVtnI44aYm8DdjdO00vFZ+YtBjdA="'
Hash Werte natürlich einpassen 😛 und in dem Zuge über HSTS nachdenken!
Zusätzlich können noch ein paar Optionen in diesem Header folgen. So zum Beispiel report-uri=”http://www.example.org/hpkpReportUrl” Hier wird über einen HTTP-Post einige Informationen vom Client im JSON Format übertragen. Also ob es Probleme gab oder nicht… Die dort folgende URL sollte demnach vielleicht nicht SSL/TLS gesichert sein, oder nicht unter der gleichen Domain liegen. Wäre im Fehlerfall ja sonst ebenfalls nicht erreichbar! Ebenfalls lässt sich mittels includeSubdomains; zusätzlich angeben, dass dieses ebenso für alle Subdomains gilt.
Einige haben es ja schon gesehen, ich habe nun doch vorzeitig mein Zertifikat von SHA1 auf SHA2 (SHA256) gehoben. Nein, ich habe nicht für das Widerrufen bezahlt 😛 Wer ins Zertifikat schaut, wird schon sehen wie ich es gemacht habe. Damit bin ich dann wohl erst einmal wieder A+…. Fragt sich für wie lange 😛 OCSP stört mich noch etwas, nicht unbedingt nötig, denn noch finde ich es ~unschön~! Jetzt nicht so unschön, dass ich es unbedingt sofort angehen muss; dennoch ist es irgendwie unschön!
Der Jabber/XMPP Server von Ignite Realtime, Openfire ist ein ganz nettes System. Leider ist das Thema Sicherheit noch nicht ganz in der aktuellen Version angekommen. Bei den Entwicklern schon. In den aktuellen Nightly Builds sind bereits die „unsichern“ Protokolle und cipher im Default aus. In der Beta geht es so… Die aktuelle stable Openfire Version 3.9.3 bietet leider weder etwas einstellbares, noch eine zufriedenstellende standard Konfiguration.
Sucht man nun im Internet nach: „how to disable weak ciphers“ in Verbindung mit Openfire findet man derzeit nur viele Menschen, welche auf der Suche nach einer gangbaren Lösung sind. Leider finden sich kaum welche 🙁
Eine Lösung möchte ich hier kurz vorstellen….
Openfire basiert auf Java. Ab Oracle Java 8 gibt es eines hier Möglichkeiten die Protokolle und Cipher zu deaktivieren, welche nicht genutzt werden sollen.
Wenn ich also von einem Debian oder Ubuntu System ausgehe und ich hinsichtlich Java nur über Openfire nachdenken muss, lässt sich mit folgender Konfiguration von Oracle Java 8 ein brauchbares Ergebnis erzielen.
In der Konfigurationsdatei: /usr/lib/jvm/java-8-oracle/jre/lib/security/java.security sollten folgende zwei Optionen gesetzte werden. Dabei ist natürlich darauf zu achten, dass sie nicht noch einmal in der Konfiguration vorkommen 😉
Damit wird SSLv3 deaktiviert, MD5 sowie RC4 werden ebenso wie einige recht schlechte Cipher nicht weiter verwendet. Mehr Informationen erhält man über die Schlagwörter: Java8 Algorithm restrictions for Secure Socket Layer/Transport Layer Security processing sowie Java8 Algorithm restrictions for certification path processing
Ein Starten und Stoppen des Openfire sollte diese Einstellungen nun aktivieren. In diesem Zusammenhang sollte natürlich noch auf die JCE Unlimited Strength Jurisdiction Policy Files geachtet werden. Diese ermöglichen höhere Bit-Stärken als 128!
Dazu passend findet sich im Postfix Logfile folgendes:
Feb 2 12:15:21 postfix/smtp[1520]: Trusted TLS connection established to domain.tld[2001:1111:1:1111::1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb 2 12:15:21 postfix/smtp[1520]: 30E4E7461347: Server certificate not verified
Feb 2 12:15:22 postfix/smtp[1520]: Trusted TLS connection established to domain.tld[1.2.3.4]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb 2 12:15:22 postfix/smtp[1520]: 30E4E7461347: to=<mailer@domain.tld>, relay=domain.tld[1.2.3.4]:25, delay=433522, delays=433521/0.09/0.63/0, dsn=4.7.5, status=deferred (Server certificate not verified)
Na? Schon eine Idee? Erst soll die TLS Verbindung trusted sein und dann doch wieder nicht? Ganz einfach 🙂 Es ist DANE…. Postfix würde ja selbst eine E-Mail zustellen, wenn er das Zertifikat nicht prüfen könnte. Hat der Empfänger aber einen TLSA-Record für sein Mailserver Zertifikat veröffentlicht und Postfix prüft dieses mit negativem Ergebnis, dann kann man wohl davon ausgehen, dass da etwas nicht stimmt. Entweder der Empfänger hat ein Problem mit seiner Konfiguration oder es versucht sich gerade jemand „dazwischen“ zu drängen.
Weiter prüfen konnte ich es mit posttls-finger:
$ posttls-finger -t30 -T180 -c -L verbose,summary domain.tld
posttls-finger: initializing the client-side TLS engine
posttls-finger: using DANE RR: _25._tcp.domain.tld IN TLSA 3 0 1 B3:E7:94:4A:CE:14:0D:CE:53:08:C6:D8:A5:D3:8C:EE:DD:94:FC:8A:B4:DD:8E:DD:DD:DD:DD:DD:DD:DD:DD:DD
posttls-finger: setting up TLS connection to domain.tld[2001:1111:1:1111::1]:25
posttls-finger: domain.tld[2001:1111:1:1111::1]:25: TLS cipher list "aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL"
posttls-finger: domain.tld[2001:1111:1:1111::1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
posttls-finger: domain.tld[2001:1111:1:1111::1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
posttls-finger: domain.tld[2001:1111:1:1111::1]:25: depth=0 verify=1 subject=/C=DE/CN=www.domain.tld/emailAddress=hostmaster@domain.tld
posttls-finger: domain.tld[2001:1111:1:1111::1]:25: subject_CN=www.domain.tld, issuer_CN=StartCom Class 1 Primary Intermediate Server CA, fingerprint=65:76:45:E3:50:1A:54:5D:BE:30:8F:DD:DD:DD:DD:DD:DD:DD:DD:DD, pkey_fingerprint=63:53:F8:60:76:8D:01:E8:57:93:EA:3C:DD:DD:DD:DD:DD:DD:DD:DD
posttls-finger: Untrusted TLS connection established to domain.tld[2001:1111:1:1111::1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Passt also wirklich nicht… Gleicher Test auf verschiedenen Systemen, gleiches Ergebnis. Ebenfalls die einschlägigen Webseiten bringen diese Meldung (https://de.ssl-tools.net/mailservers/).
Ich muss zugeben, ist eine Premiere für mich. Also ein wirklich echt fehlgeschlagener DANE Test von Postfix, welcher die Mailzustellung verhindert hat. Natürlich hat postfix nicht nach dem ersten Versuch aufgegben, diese Prüfung führt zu einem temporären Fehler der 4xx Reihe. Postfix versucht es also ein paar Tage. In meinem Fall hat also alles genau so funktioniert, wie ich es mir gewünscht habe. Postfix testet die TLSA-Records, bemerkt einen Fehler, logt diese und probiert es noch einmal. Der Fehler bestand dauerhaft und Postfix gab mir die Mail zurück, mit der Info das etwas mit dem Zertifikat des Empfängers nicht stimmt. Das hat Postfix wirklich gut gemacht *tätschel*
Inzwischen hat ja fast jeder bei uns „schnelles“ Internet…. So lassen sich per E-Mail auch mal etwas größere Dateien verschicken. Dennoch sollte man so ab 5MB ein schlechtes Gefühl haben und sich ab 10MB Anhängen nicht mehr über abgewiesene E-Mails ärgern.
Das Problem mit großen Dateianhängen bei E-Mails ist ja nicht nur die Verstopfung der Leitungen… Mailserver arbeiten sich daran ab, der absendende und empfangende Client ebenfalls. Hängt dann noch ein Virenscanner dazwischen rechnet noch jemand. Dann liegt die Datei auf dem System des Absenders, in dessen Postfach, im Postfach dem Empfängers und natürlich noch auf dem System des Empfängers. Bei einem 500MB Anhang sind das schon mal 2GB für nix.
Inzwischen gibt es 1000 Möglichkeiten um große Dateien schnell und einfach auszutauschen. Selbst ohne seine Daten auf irgendeinen Server bei irgendeinem Anbieter zu legen. So zum Beispiel über owncloud….. Hochladen muss man die Datei ja in jedem Fall zu seinem Mailserver, warum also nicht lieber in die „Cloud“? Ok, es ist etwas aufwendig. Erst hochladen, dann teilen, dann den Link kopieren und in die E-Mail packen, usw. usw…
Für Anwender des Mailclients Thunderbird gibt es in diesem Zusammenhang eine noch schönere Lösung. Sie nennt sich filelink. Im Grunde nichts weiter als eine kleine Funktion, welche dem Anwender etwas Arbeit abnimmt!
Hängt der Anwender eine Datei an seine E-Mail an, welche einen einstellbaren Schwellwert überschreitet, schlägt Thunderbird diesem vor, den Anhang für den Anwender in einen dieser „Austauschservices“ zu laden. Stimmt der Anwender zu, schiebt Thunderbird die Datei hoch und verlinkt sie automatisch in den E-Mail Body. Dieses hält die E-Mai klein und der Empfänger kann selbst entscheiden, ob und wann er den „Anhang“ herunterladen möchte.
Aktuell bringt Thunderbird aus dem Karton leider nur die Verknüpfung zu den bekannten großen Anbietern wie z.B.: dopbox mit. Dort möchte man ja nicht unbedingt seine Daten ablegen. Für owncloud habe ich vor kurzem eine gut funktionierendes Thunderbird Plugin gefunden:
Einfach herunterladen, installieren, zwei drei Kleinigkeiten in der eigenen Cloud einstellen und glücklich sein 🙂 Mit zwei/drei erklärenden Sätzen in der E-Mail versteht es zudem fast jeder Empfänger. Noch Fragen?
Ich experimentiere in der letzten Zeit etwas mehr mit PC-BSD herum und so langsam verdrängt es sogar seinen Vater FreeBSD von meinem Desktop….
Der angenehme Vorteil von PC-BSD ist, dass es bereits viele Kleinigkeiten für den Desktopeinsatz „fertig“ vorhält. Man muss nicht erste jede Kleinigkeit selbst konfigurieren (ich werde SO faul). Der Nachteil ist, man lernt nix mehr 🙁 Wie auch immer…
Ich wollte gerade eine CD brennen, starte mein xfburn und dieses erzählt mir es könne keinen Brenner finden oder die Berechtigungen würden nicht stimmen.
** (xfburn:12447): WARNING **: No drives were found! If this is in error, check the permissions
Nanu?!?! Als erstes wollte ich die Berechtigungen ausschließen:
$ pc-su xfburn
Passwort:** Message: Using elementar transcoder.
Brennen klappt… Also wirklich ein Problem mit den Berechtigungen. Dann schauen wir sie uns mal durch..
Der Brenner ist im Notebook das Device /dev/cd0 mal sehen…
$ ls -lisa /dev/cd0
105 0 crw-rw-rw- 1 root operator 0x69 21 Jan 07:40 /dev/cd0
Sieht doch gut aus… Viele Anwendungen nutzen aber einen Link um auf das jeweilige Laufwerk zuzugreifen, auch wenn es der Brenner nicht tun sollte, denn… (dazu später)… mal schauen und gelesen haben stört aber nicht 🙂
$ ls -lisa /dev/cdrom
131 0 lrw-rw-rw- 1 root wheel 3 21 Jan 07:43 /dev/cdrom -> cd0
$ ls -lisa /dev/dvd
132 0 lrw-rw-rw- 1 root wheel 3 21 Jan 07:43 /dev/dvd -> cd0
Pass bei mir aber auch, sollte es nicht passen hilft bei Symlinks ein chmod -h 0666…. Nur würde es beim Problem mit dem Brenner nicht helfen! Warum? Nun ja, wer sich an „früher“ unter Linux erinnert, da musste man auch ein Modul laden, welches aus dem ATA Brenner einen SCSI Brenner für den Kernel macht. Funktioniert noch immer ähnlich, ist aber inzwischen im Linux Kernel verklappt. Unter BSD muss man noch immer dafür sorgen. Dafür müssen in der Datei /boot/loader.conf folgende Einträge erstellt werden:
atapicam_load="YES"
hw.ata.atapi_dma="1"
Der erste Eintrag sorgt dafür, dass der ATA Brenner als „SCSI“ Laufwerk ~erkannt~ wird, der zweite aktiviert den DMA Zugriff auf ATA Laufwerke. Ich meine dass im Kernel vom PC-BSD bereits per Default DMA für ATA Geräte aktiviert ist, schadet aber nicht! Ach ja, in meiner PC-BSD loader.conf gab es den nötigen Eintrag bereits. Es war also schon richtig, denn noch ging es nicht 🙁
Macht nix, weiter suchen! Ist das Modul geladen, sollte mir camcontrol nun meine ATA Geräte auflisten können, inkl. deren SCSI ID und dem zugehörigen passthrue Device:
cd0 stimmt, habe ich bereits kontrolliert. pass1? Mal sehen:
$ ls -lisa /dev/pass1
76 0 crw------- 1 root operator 0x4c Jan 21 07:40 /dev/pass1
Na schau mal einer an 😀 Zum Test setzte ich mal passende Rechte auf das Device und starte dann als User mein Brennprogramm.
$ chmod 0666 /dev/pass1
Geht… Dann soll es so bleiben! Nach einem Reboot wären meine vergebenen Rechte wieder weg. Damit diese bleiben muss ich meinen Wunsch in der Datei /dev/devfs.conf hinterlegen. Ein Blick in diese verrät mit, dass sich schon jemand Gedanken gemacht hat (pc-bsd halt…). So sind bereits passende Rechte für das Gerät /dev/pass0 gesetzt. Nur eben nicht für /dev/pass1. Es lässt sich also einfach der Eintrag von pass0 für pass1 kopieren:
/etc/devfs.conf
....
# Commonly used by many ports
link cd0 cdrom
link cd0 dvd
....
# Allow all users to access CD's
perm /dev/acd0 0666
perm /dev/cd0 0666
....
# Misc other devices
own /dev/lpt0 root:cups
perm /dev/lpt0 0666
own /dev/lpt1 root:cups
perm /dev/lpt1 0666
perm /dev/pass0 0666
perm /dev/pass1 0666
....
Nur ein Detail welches noch beim PC-BSD fehlt um es für den Benutzer beim Brennen noch einfacher zu machen. Wenn auch ein Detail, was Benutzer ohne FreeBSD Vorkentnisse ins Straucheln bringen könnte.
Man man man… Was ist denn da passiert? Seit 3 oder 4 Tagen scheint das Thema im Internet irgendwie besonders aktiv zu sein, oder? Nur warum?!?!
Plötzlich bekomme ich nicht nur jeden Tag einen Haufen Anfragen zu dem Thema, viel scheinen auch irgendwas testen zu wollen und pumpen E-Mails mit Random-Empfängern an meine Domains….
Im Grunde habe ich ja nichts gegen Tests. Nur grob abgesprochen wäre schon schön, mein Monitoring wird sonst immer so „wuschig“! 😀
Um noch mal ein paar Themen zusammen zu fassen:
1. Basis von allem ist DNSsec 2. TLSA Records „ist DANE“ 3. Postfix kann TLSA Records auswerden, ohne selbst welche für sein System zu haben.
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept All”, you consent to the use of ALL the cookies. However, you may visit "Cookie Settings" to provide a controlled consent.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Dauer
Beschreibung
cookielawinfo-checkbox-advertisement
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category .
cookielawinfo-checkbox-analytics
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Analytics" category .
cookielawinfo-checkbox-necessary
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Necessary" category .
cookielawinfo-checkbox-others
1 year
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Others".
cookielawinfo-checkbox-performance
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to store the user consent for cookies in the category "Performance".
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Dauer
Beschreibung
CONSENT
16 years 3 months 22 days 14 hours
These cookies are set via embedded youtube-videos. They register anonymous statistical data on for example how many times the video is displayed and what settings are used for playback.No sensitive data is collected unless you log in to your google account, in that case your choices are linked with your account, for example if you click “like” on a video.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Dauer
Beschreibung
yt-remote-connected-devices
never
These cookies are set via embedded youtube-videos.
yt-remote-device-id
never
These cookies are set via embedded youtube-videos.
