Synology-Forum.nl
Overige software => DDNS / Quick Connect / EZ-Internet / Portforwarding => Topic gestart door: NTC1985 op 14 augustus 2017, 21:15:37
-
Beste DS-gebruikers,
Al enige tijd probeer ik de https-verbinding tussen mijn pc en de NAS veilig te krijgen. Ik heb me inmiddels een week ingelezen en van alles geprobeerd, maar ik krijg het simpelweg niet voor elkaar.
Ik heb in eerste instante het zelfondertekende certificaat van Synology gebruikt, maar die werd niet herkend door Chrome. Vervolgens heb ik een certificaat met Lets Encrypt aangemaakt, welke wél wordt herkend. De verbinding is echter nog altijd niet veilig. Ook niet in Explorer. Het enige dat mij is opgevallen is dat ik bij het exporteren van een certificaat *.pem-bestanden krijg en geen *.crt. Maar omdat Chrome in ieder geval het Lets Encrypt certificaat herkend en dit certificaat ook door Windows wordt herkend, denk ik niet dat daar een probleem ligt.
Ik heb ook de nodige poorten (5001, 443, etc) geforward, maar ook dat mag niet baten. Iemand nog een idee? Ik hoor die zeer graag, want het is me een doorn in het oog (ondanks dat ik heb gelezen dat een 'niet-veilige' https-verbinding nog altijd beter is dan een gewone http-verbinding.
-
Waarom is de verbinding niet veilig bij een zelfondertekend certificaat? Als dat een browsermelding is, is dat eerder een fout in de browser. Chrome en Firefox zijn gewoon gek geworden met hun agressieve meldingen.
-
@NTC1985 Goed stappen plan.
Let wel op; de certificaten StartSSl worden niet meer als veilig gezien door de browsers. dit schijnt te komen omdat StartSSL tegenwoordig in Chinese handen is.
Verstuurd vanaf mijn SM-A510F met Tapatalk
-
Als dat een browsermelding is, is dat eerder een fout in de browser.
Beste Briolet,
Ik kom (via lokale ip-adres) nu zonder waarschuwing binnen, maar in de adresbalk staat 'niet veilig' in plaats van dat ik een groen slotje zie. Via ***.synology.me:5001 krijg ik nog steeds een melding over Web Server, dus dat werkt ook nog niet naar behoren.
Inmiddels heb ik het certificaat ook op mijn telefoon (iOS) geïnstalleerd, maar ik zie niet dat sprake is van veilige verbinding.
Verzonden vanaf mijn iPhone met Tapatalk
-
Goed stappen plan.
Beste Tieske,
Dat stappenplan, ondanks dat het aanmaken van certificaten via StartSSL is achterhaald, heb ik meerdere keren zorgvuldig bestudeerd. Helaas zonder resultaat.
-
Bij mij werkte het eerst niet goed, kreeg nooit de mail vat startssl. dit kwam omdat ikk ddns doorverwijzing had. nadat ik die had opgegeven kwam de bevestigingsmail wel binnen
Echter heb ik DS710 die met DSM5.2 werkt, 6.x is helaas niet beschikbaar voor dit model.
Verstuurd vanaf mijn SM-A510F met Tapatalk
-
Een kennelijk nog steeds breed heersend misverstand:
Het "veilig" zijn van een https verbinding kent twee aspecten:
* is de server wie hij beweert te zijn (server identiteit) en
* versleuteling van de data
Een https verbinding is altijd versleuteld, en kan dus niet (of ten koste van zeer veel moeite)
worden ontcijferd zonder over een sleutel te beschikken.
De identiteit van een server wordt geverifiëerd middels een officieel (erkend) certificaat.
Een "man in the middle" kan zich dan niet voordoen als de echt bedoelde server.
Zonder officieel certificaat zou een "man in the middle" zich voor kunnen doen als bijv. een bank,
en daarmee in de https communicatie met jou effectief over de sleutel beschikken.
Het hangt er dus maar net vanaf waarom je met https wil werken:
Wil je slechts je (web)data versleuteld over internet versturen, dan kan je best zonder certificaat.
Ben je een interessant doelwit voor kwaadwillende hackers (bijv. een bank), ga dan voor een officiëel certificaat.
Mijn mening: self certification zit er een beetje tussenin, maar is geen vlees en geen vis.
-
@Tieske en @NTC1985 Niet onnodig citeren of onnodig alles citeren.
-
Ook met een self signed certificaat is geen "man in the middle" aanval mogelijk. Jij bent nml de uitgeven van het certificaat en kunt het zelf op echtheid controleren. Dat is in mijn optiek eerder veiliger dan minder veilig dan een officieel certificaat.
Het is het probleem van Chrome dat je geen uitzonderingen kunt toevoegen bij een mismatch tussen de naam op het certificaat en de naam waarmee je inlogt. De meeste andere browsers laten dat wel toe.
In een self-signed certificaat kun je ook IP nummers opnemen. Dat deed ik ook voordat ik certificaten van Let's Encrypt ging gebruiken. Alleen dan moet je het certificaat helemaal zelf maken (heb ik hier ooit eens uitgelegd), want de tool van Synology laat alleen domeinnamen toe in een self-signed certificaat.
-
@Birdy Excuus!
Verzonden vanaf mijn iPhone met Tapatalk
-
In een self-signed certificaat kun je ook IP nummers opnemen. Dat deed ik ook voordat ik certificaten van Let's Encrypt ging gebruiken.
Heb jij - met een certificaat van Let's Encrypt - nu dan ook (nog) een groen slotje in de adresbalk van jouw browser?
Ik heb jouw post overigens gelezen over hoe zelf te knutselen in een certificaat. Zeer interessant, maar ik hoop dat vooralsnog niet nodig te hebben.
Uit de reacties leid ik wel af dat ik met een 'groen slotje' niet beter beschermd ben dan zonder.
Verzonden vanaf mijn iPhone met Tapatalk
-
Als je inlogt met de url die je voor het certificaat opgegeven hebt, dan is het slotje gewoon groen bij Let's Encrypt
[attachimg=1]
Ik gebruik meerdere domeinen en subdomeinen in het certificaat. Ook mijn *.synology.me url staat in het certificaat. Je moet wel elk subdomein opnemen.
Edit: Ik zie net dat ook Firefox de verbinding als "niet veilig" aangeeft als je met een andere url inlogt dan in het certificaat vermeld staat. Ook al heb je een uitzondering toegevoegd.
Ik vind dat een slechte ontwikkeling omdat dit mensen aanleert om dan toch maar met een "niet veilig" melding verder te werken.
Ik werk met altijd met Safari. Daar kun je gewoon een uitzondering voor een andere url toevoegen die je dan met het inlog-wachtwoord van je mac moet bevestigen.
-
@Briolet Als domeinnaam heb ik bij het certificaat van Let's Encrypt vermeld ***.synology.me, evenals bij het alternatieve adres. Als email heb ik ***@gmail opgegeven.
Jouw redenering volgend moet ik dus met evengenoemde domeinnaam inloggen, omdat daarmee het certificaat is aangemaakt. Dat klinkt eigenlijk heel logisch. Ik krijg dan alleen de volgende melding: (https://uploads.tapatalk-cdn.com/20170815/e88fc0f7046e98fe6fa6b9509906fde4.jpg) Wat gaat hier mis?
Ik ga morgen sowieso ook nog even Safari testen.
Verzonden vanaf mijn iPhone met Tapatalk
-
Daar is niets mis mee. Als je geen poort opgeeft, kom je op de webserver terecht, mits geïnstalleerd. Maar voor die tijd moest je toch ook al poort 5001 opgeven voor DSM?
-
@Briolet Zojuist weer wat zitten stoeien. In plaats van ***.synology.me - waarmee ik zowel via LAN als WAN op de Web Server uit kwam (terwijl ik poort 5001 in mijn router heb doorverwezen naar de juiste NAS) - heb ik ***.quickconnect.to gebruikt. Via LAN kom ik nu wel bij DSM uit, alleen is de verbinding niet veilig. Maar wat blijkt nu, als ik via mijn telefoon (4G) via Chrome het quickconnectadres gebruik, is daar het felbegeerde groene slotje. Heb je wellicht nog een idee hoe ik dat ook intern voor elkaar krijg (hoewel misschien van ondergeschikt belang)?
Dank voor je reacties tot op heden btw. Wordt zeer gewaardeerd!
-
Wat ik overigens niet begrijp is het volgende. Om na te gaan of het certificaat op mijn telefoon daadwerkelijk een functie heeft, heb ik het van mijn telefoon verwijderd. Dit heeft in mijn geval geen invloed op de veiligheid van de verbinding van mijn telefoon met de NAS. Het groene slotje is nog steeds zichtbaar. Dat is zou toch eigenlijk niet moeten?
-
Ik heb nog nooit QC gebruikt, maar wat is er van weet is dat hij probeert locaal te verbinden. Maar met een QC-url, klopt je certificaat nooit.
Via je telefoon zit je extern en gebruikt QC de servers in de UK. Waarschijlijk loopt dat via een ander certificaat.
Maar primair zit het probleem in Chrome, die niet toestaat om een verbinding vanaf je lan wel veilig te verklaren. Chrome gaat er gewoon vanuit dat je hun browser nooit gebruikt voor iets op het lokale netwerk.