Problemen na toevoegen certificaat

[J-J]

Je kan inderdaad alles over beveiligde connecties laten lopen (als je jouw huisgenoten niet vertrouwd )

Maar binnen je thuisnetwerk vind ik het wat overkill…
Niet alle webservices zijn bereikbaar over https en dat lost de reverse proxy dus voor je op door https naar http om te leiden.

[Briolet]

Bij een reverse proxy (RP) die naar localhost verwijst is dat niet alleen binnen je lan, maar zelfs binnen je nas. Als je bang bent dat iemand binnen je nas een onbeveiligde verbinding aftapt, dan ben je paranoïde. Want dan kunnen ze ook een printbaan verder aftappen omdat het verkeer uiteindelijk ergens in de nas onbeveiligd aanwezig is. Al was het maar om te kunnen verwerken.

Bij een RP komt het verkeer binnen met de versleuteling via het certificaat van deze RP. Vervolgens wordt het ontsleutelt. Vervolgens stuurt hij het door naar de DSM pagina. Als dat een versleutelde verbinding is, moet het weer gecodeerd worden met het certificaat dat aan DSM toegewezen is. Vervolgens moet DSM dat weer ontsleutelen.

Maar omdat het hele doorsturen naar localhost (Of het IP van de nas zelf) binnen de nas gebeurd is het paranoia om dit beveiligd te doen.

[Babylonia]

Het gaat er mij niet om dat je binnen je LAN een wel of niet beveiligde verbinding zou willen hebben, maar de onlogische keus van omzettingen. Precies de reden waarom in het onderhavige geval bij gebruik van de DS File app een "beveiligde" poort 443 toegevoegd zou moeten worden, om vervolgens een "onbeveiligde" verbinding te willen opzetten?

Dat is net zo'n gebaar als bij een autorit "buiten" de veiligheidsgordels in een auto loskoppelen om daarmee "geen veiligheidsrisico's" te lopen.
En bij parkeren van de oprit om de auto vervolgens nog net even onder de carport te zetten, wel de veiligheidsgordel vast te koppelen.

Lijkt me logischer om bij gebruik binnen het interne LAN de keus voor "HTTPS" in de DS File app uit te vinken.
En bij externe benadering wel een vinkje / activatie voor HTTPS.

[Briolet]

@Babylonia , leg me toch nog eens uit waarom je dataverkeer dat je nas niet verlaat, moet encrypten en weer decrypten. Alleen omdat je het van de ene naar de andere poort doorstuurt. Ik zie daar echt geen meerwaarde in, alleen extra werk voor de CPU.

Volgens mij moet je je eerst eens verdiepen in de werking van een reverse proxy.

[Rubensky]

Best een leuk topic als je alleen je reverse proxy niet ingesteld krijgt, maar die na 24 uur ineens wel blijkt te werken...
Het klopt dat het overkill is om intern alles via een beveiligde verbinding te laten lopen.

[Babylonia]

@Babylonia , leg me toch nog eens uit waarom je dataverkeer dat je nas niet verlaat, moet encrypten en weer decrypten.

Dat is de discussie helemaal niet waar het om gaat.  Dat schreef ik nu net in die voorafgaande reactie.

[Briolet]

Daar gaat het juist wel om, maar jij verdraait de dingen in jouw reactie.  Jij reageert op het opzetten van een reverse proxy. De laatste stap daarin kan speelt geheel intern in de nas af en kan dus een onbeveiligde poort zijn. Maar dat betekent niet dat je een onbeveiligde verbinding opzet.

Voor de gebruiker wordt er gewoon een beveiligde verbinding opgezet tot in de nas. Hij ziet ook alleen de https verbinding in de browser met het certificaat van de reverse proxy.. Het onbeveiligde stuk gebeurd achter de reverse proxy.

[Rubensky]

Kunnen we even terug naar mijn vraag? Want, daar ik wil nog iets vragen.

Op mijn PC heb ik de Drive Client draaien. Die is lokaal verbonden via mijn lokale IP adres met de NAS. Als ik in het certificaat menu mijn certificaat koppel aan de Synology Drive Service krijg ik op mijn PC steeds de melding status niet normaal. Er wordt dan ook niet gesynchroniseerd.

Zet ik de Synology Drive Server op het certificaat van Synology dan werkt een en ander wel.

Hoe kan dit?

[Babylonia]

Daar gaat het juist wel om, maar jij verdraait de dingen in jouw reactie.

Nee, ik verdraai niks.  Maar kennelijk begrijp je helemaal niet waar ik op doel?
Er worden verwarrende poortnummers gebruikt in het toelaten van wel of geen beveiligde verbindingen.
Niets meer,  niets minder !

Poortnummer 443 wordt internationaal gebruikt voor een beveiligde verbinding.
Die zou je om die reden dan ook niet moeten gebruiken voor verwijzingen naar "niet" beveiligde connecties.

Koud stromend water, wordt bij een kraan aangeduid met een "blauw" dopje / merkteken op de kraan.
Bij warm water, met een "rood" dopje / merkteken op de kraan.
Gewoon internationaal een normaal begrip voor koud en warm water.  Wat ieder als zodanig gewend is te gebruiken.

Kun je voor eigen gebruik die gekleurde dopjes wel omwisselen.
Een blauw dopje voor warm water of andersom een rood dopje voor koud water.
Dat zal toch voor verwarring gaan zorgen.  En in die verwarring vroeg of laat onbedoelde situaties opleveren,
omdat anderen die ermee worden geconfronteerd, niet gewend zijn aan die "verkeerde" aanduiding waar het voor staat.

Bij gebruik van connecties en poortnummers idem.
Houd je simpel aan de doorgaans gebruikte standaard afspraken waar die poortnummers voor staan.
Niets meer, niets minder.

Wil je iets doorsturen naar een onbeveiligde verbinding in die conversie met gebruik van poortnummers,
gebruik dan bijv. poort 8080 ----> naar poort 5000

Beveiligde verbinding     443 ----> naar poort 5001   (of bijv.  4443 ----> naar poort 5001 )

Dan is voor iedereen duidelijk wat er wordt bedoeld.  Datgene wat  @Rubensky  eerder heeft opgezet < HIER >
Dat lijkt me de juiste aanpak.

Met wat ik begrijp op te maken in een eerdere reactie van @J-J wordt gesuggereerd poort 443 te gebruiken voor poort 5000 ??

[J-J]

Kunnen we even terug naar mijn vraag? Want, daar ik wil nog iets vragen.

Op mijn PC heb ik de Drive Client draaien. Die is lokaal verbonden via mijn lokale IP adres met de NAS. Als ik in het certificaat menu mijn certificaat koppel aan de Synology Drive Service krijg ik op mijn PC steeds de melding status niet normaal. Er wordt dan ook niet gesynchroniseerd.

Zet ik de Synology Drive Server op het certificaat van Synology dan werkt een en ander wel.

Hoe kan dit?

Op je PC/Mac hoef je normaal niets aan te passen in Synology Drive station.
Deze werkt via Quickconnect. Tenzij je dit niet ingesteld hebt…

[Rubensky]

Ik gebruik geen Quickconnect maar een eigen certificaat. Na het instellen daarvan moest ik opnieuw verbinden. En krijg ik de melding zoals ik hierboven schreef.

[J-J]

Heb je een nieuw certificaat aangemaakt voor een nieuw Synology drive subdomein? (bv drive.mijndomein.nl) Een certificaat voor het ene subdomein werkt niet voor een andere subdomein (tenzij je een ”wildcard” certificaat aanmaakt)

Kan je via de browser bij Synology Drive geraken? (via subdomein)


Als server om mee te verbinden heb je dus op je PC het subdomein voor Synology Drive station ingeven, gevolgd door poort 443
(drive.mijndomein.nl:443) veronderstel ik?

[Rubensky]

Niet helemaal zoals je veronderstelt. Wat ik heb gedaan is via de opties bij het certificaat (instellingen --> configureren. Daar heb ik het Synology.com certificaat vervangen voor mijn eigen certificaat.

Dat had ik dus ook gedaan voor de Synology Drive Server.

De Drive Client op mijn PC is verbonden met mijn NAS via mijn lokale 192.168.x.x IP adres. (De bewuste PC hangt in hetzelfde netwerk).
En dan krijg ik dus de melding Status niet normaal. En wordt er niet gesynchroniseerd.