Kun je niet beter de QR-code scannen en het document printen en in de doos bewaren? Of sla het document digitaal ergens op nu het nog beschikbaar is.

Alle 'beveiligingsissues' zijn zo algemeen dat dit voor bijna alle vergelijkbare situaties geldt.
De overige vragen kan iedereen slechts naar gissen, daar kan alleen Asus jou antwoord op geven.

Ik weet het niet zeker, maar

1 - bijna geen hond leest mobo handleidingen, laat staan de detailed pinouts. Het is dus fors nutteloos om gebruikers te volgen.
(tip voor supernerds: leer dat je eigen gedrag/interesse *niet representatief* is, en hang dus geen theorie of advies 'voor alle gebruikers' op aan je voorkeuren.)
2 - dat zal wel niet, een pagina meer of minder maakt niet uit. Of misschien wel, als het echt veel papier is tov van de rest van de handleiding.
3 - het zal vooral productieproces-vriendelijk zijn, met misschien ook wat voordelen voor de gebruiker.


Wat Asus bereikt met een QR code (of gewoon URL) in een handleiding is dat die informatie losser staat, en onafhankelijk te updaten is van de rest .

Ik vermoed dat de detailed pinouts misschien wat later in het ontwerpproces bepaald worden, of deels gegevens bevatten die pas laat beschikbaar komen, of wie weet een historie van fouten en correcties hebben.

Door de verwijzing naar de detailed pinouts dynamisch te maken, blokkeren die gegevens niet het afmaken van de rest van de handleiding. (Ook dat heeft een doorlooptijd - maken, controleren, en dan laten drukken). Als dat proces voorheen opgehouden werd door het beschikbaar komen van de detailed pinouts hebben ze dat opgelost.
Een voordeel voor de gebruiker kan zijn dat zo'n stukje dynamische handleiding bijgewerkt kan worden als er errata in eerdere versies zaten.

Ik vind het juist HEEL HANDIG als handleidingen niet op een A6 formaat in de doos gepropt worden maar als PDF
beschikbaar zijn zodat je ze zelf op de gewenste grootte kunt afbeelden, kunt doorzoeken, etc.

Wel sla ik de gedownloade handleiding voor zo iets altijd op.

De eerste QR-code bevat als link: http://c3.clewm.net/BQnEfp
En de tweede (voor de BIOS update guide): http://c3.clewm.net/BzlxKN

Het lijkt om URL-shorteners te gaan waardoor je niet weet waar je uitkomt. Zelfs als c3.clewm.net betrouwbaar is, wordt de kans, dat je daadwerkelijk op die site uitkomt, verlaagd doordat het om http (i.p.v. https) links gaat.

Ik vind het vreemd dat Asus de bedoelde documenten niet op haar eigen website beschikbaar stelt (desnoods elders met links vanaf die Asus website). Ook vind ik het gek dat Asus je dwingt om een QR-code lezer te gebruiken; waarom staan die URL's niet (tevens) plain-text in de manual? Wellicht schaamt Adus zich ervoor dat ze niet naar hun eigen website (maar naar een Chinese) verwijzen met nog http links?

Als test heb ik die tweede link op VirusTotal ingevoerd: https://www.virustotal.com/#/url/ef666d9264b2784ae04aa8319bf33938f3f8b89bc43f198988d08f4814d51f91/details. Volgens Avira zou het om malware gaan, maar dat kan best een alarm zijn voor een andere URL-shortener code (dan BzlxKN op c3.clewm.net).

In de details-pagina zie je dat je inderdaad wordt doorgezet naar een https link, maar als een aanvaller het DNS-request voor c3.clewm.net met het IP-adres van een andere site beantwoordt, of als MitM in de netwerkverbinding zit, kom je niet uit op de bedoelde site en krijg je daar ook geen waarschuwing of foutmelding voor te zien.

Toch ook die eerste link maar even ingevoerd: https://www.virustotal.com/#/url/c634a4436a622c40ed60e4d313d346d44a37c1b45e02f2b24914c8a0c4122d88/details. Zoals ik verwachtte slaat Avira ook aan op deze URL.

De PDF van de eerste QR-code bevat Javascript met "an open action to be performed when the document is viewed" (zie https://www.virustotal.com/#/file/efbf8c3e20d227c3621776c5c735b89ae811e411fddd264b03b7f37d6ef81a25/details). Mogelijk wordt er "naar huis gebeld" zodra je de PDF opent in een PDF-viewer die Javascript ondersteunt en uitvoert.

Rommelig en niet erg professioneel van Asus.

@16:03 Ik zie in de link van Bitwiper dat het betreffende document al uit 2015 is. Het wordt dus niet op het laatste moment aangepast aan het moederbord.

Er zijn wel verschillende typen System Panel Connectors in de .pdf:
10-1 pin F_PANEL, 20-8 pin PANEL, 20-5 pin PANEL en 20-3 pin F_PANEL.

Maar dit type connector staat dan ook in de gedrukte handleiding van je moederbord, dus dan kunnen ze meteen het juiste plaatje erbij kopiëren en plakken. Dat is voor mij veel makkelijker.

@Bitwiper: De korte links wist ik niet. Ik heb geen smartphone dus ik heb iemand in mijn omgeving gevraagd de QR code in te scannen. Deze persoon kwam meteen met een gigantische https link naar de .pdf. Ik was al verbaast dat die helemaal in de QR code paste.

(16:03 hier).
Dat is nog niet te zeggen - mogelijk hebben ze een paar smaken van pinout layouts, en linken ze naar de gekozen versie bij een bepaald model moederbord op moment dat de keuze definitief is.



Ik zou zelf ook het liefst alle informatie bij elkaar hebben .

Ik kan dus alleen maar kijken wat ze effectief bereikt hebben (los(ser) koppelen van pinout informatie van de rest van de mobo handleiding) , en speculeren waarom dat voor Asus handiger zou kunnen zijn. En dan denk je aan verschillende stromen in het productie/ontwerpproces die pas laat bij elkaar komen en de oplevering gaan vertragen wanneer de handleiding pas kan beginnen als alles bij elkaar gekomen is.

DNS Hijack voorkom je niet met https. Want een sessie start met een DNS lookup, nog voor https.

DNS Hijack voorkom je o.a. met DNSSEC. Een https verbinding betekent alleen dat in de data niet gekeken kan worden, anders dan het IP-verkeer.

Wil je de DNS lookup ook afschermen, dan heb je daarvoor DNS-over-TLS (DoT) en DNS-over-HTTPS (DoH). Maar dan is nog steeds bekend welk IP met welk IP communiceert. Zeker wanneer je SNI niet hebt adgeschermd.

Klopt, MitM aanvallen, BGP hijacks en stroomstoringen kun je ook niet voorkomen door https te gebruiken.

De kracht van https zit er echter in dat jouw browser een foutmelding geeft als de https verbinding wordt gemaakt met een server die niet over een geldig certificaat (plus bijbehorende private key) beschikt voor de gegeven domeinnaam.

Als DNSSEC een perfecte oplossing was geweest zou iedereen het allang gebruiken. En zelfs als iedereen het zou gebruiken, zou http daamee niet net zo veilig worden als https.

Nee, een https verbinding (zonder foutmelding) betekent in de eerste plaats dat je zeker weet dat jouw browser een verbinding heeft opgezet met een server die beschikt over een door jouw browser als geldig geaccepteerd certificaat (waarbij die server tevens over de bijbehorende private key moet beschikken) voor de, in de URL-balk van jouw browser, getoonde domeinnaam.

Na die validatieslag wordt de verbinding versleuteld - niet alleen op een manier die afluisteren onmogelijk maakt, maar ook zodanig dat wijzigingen aan de uitgewisselde informatie worden gedetecteerd en tot foumeldingen leiden. Onopgemerkte MitM aanvallen zijn daarmee onmogelijk (tenzij de aanvaller over een geldig certificaat (+ private key) beschikt voor de betreffende domeinnaam en/of er sprake is van bugs en/of kraakbare encryptie).

Mijn punt was dat als een verbinding met http begint en vervolgens overgaat in https, deze verbinding vóór de stap naar https gekaapt kan worden - zonder dat dit tot foutmeldingen leidt. DNSSEC beschermt je hooguit tegen aanvallen op DNS, verder niet.

QR-codes zijn om nog wel meer redenen een beveiligingsissue:
https://en.wikipedia.org/wiki/QR_code#Risks !!!!!

Het zit in de natuur van mensen om QR-codes te scannen. Omdat mensen nieuwsgierig zijn wat er achter zit.
Vooral als de QR-code samen gaat met een lokkende tekst.
Maar je kan er gemakkelijk heel lelijk mee op je snoet gaan, dus pas op.
Zelf zou ik geen QR-codes scannen, tenzij het mijn allerlaatste hoop in nood is.

Die link is nog niets. Een QR code kan meer bevatten dan je denkt. Het ligt een beetje aan het aantal pixels, maar een standaard code kan toch snel een paar honderd tekens aan. De url moet wel extreem zijn, wil het niet meer passen.

Dat is ook de reden dat het niet goed te praten is dat er een url-shortener gebruikt wordt als link.

Naar aanleiding van de bijdrage van de TS heb ik gegoogled naar een veilige en privacy-vriendelijke QR scanner app (voor mijn Android smartphone) en vond zo https://secuso.aifb.kit.edu/english/QR_Scanner.php (onderaan de pagina vind je een link naar de sourcecode op Github).

Deze app doet desgewenst niets met het resultaat van de scan (anders dan dat resultaat te tonen). Hiermee heb ik de QR codes uit de Asus manual gescand (door de manual in m'n iPhone te openen, ik heb nog niet uitgezocht of de app ook QR-codes uit screenshots of andere apps kan scannen). Deze app kan overigens ook barcodes scannen.

Die SECUSO groep heeft overigens nog meer interessante apps, maar ze lijken niet allemaal even goed onderhouden te worden.