| 8 Mar 2021 |
 tarzanell0 | In reply to @telegram_647039043:t2bot.io
A tal proposito ho una domanda. Visto che il mio server selhosted in docker lo userei solo internamente nella LAN, ha senso attivare HTTPS? Da quanto ho capito ngix fa da reverse proxy in modo che tutte le richieste e dati passano da lui in forma criptata con HTTPS e poi giungano al mio container/server Nextcloud. Però io non ho la necessità che il mio container sia visto dall'esterno... Come dice giustamente Michelangelo è più uno scrupolo maggiore.. puoi tranquillamente farti un certificato self signed con openssl e poi, in base al tuo backend, lo carichi .. così avresti connessione ssl in lan.. ma ripeto è più uno scrupolo maggiore (io lo farei onestamente) | 08:39:05 |
 Mark | In reply to @tarzanell0:matrix.org
Come dice giustamente Michelangelo è più uno scrupolo maggiore.. puoi tranquillamente farti un certificato self signed con openssl e poi, in base al tuo backend, lo carichi .. così avresti connessione ssl in lan.. ma ripeto è più uno scrupolo maggiore (io lo farei onestamente) Come si fa? Guide? | 09:07:43 |
 Michelangelo | In reply to Mark
Come si fa? Guide? puoi usare mkcert https://github.com/FiloSottile/mkcert | 09:15:19 |
| Michelangelo | è abbastanza facile da capire e usare, poi i certificati li devi piazzare nella cartella che vuole il tuo backend | 09:15:50 |
| Mark | In reply to Michelangelo
puoi usare mkcert https://github.com/FiloSottile/mkcert Grazie ci do un occhio | 09:15:54 |
| Michelangelo | In reply to Mark
Grazie ci do un occhio giusto una nota finale, non è pensato per essere usato fuori da una rete interna, perchè ovviamente i certificati non sono firmati e quindi sono è consigliabile usarlo su indirizzi pubblici/esterni | 09:19:58 |
| Michelangelo | è nato per chi sviluppa e non vuole sbattersi ogni volta a fare certificati, impostare etc etc | 09:20:39 |
| Mark | In reply to Michelangelo
è nato per chi sviluppa e non vuole sbattersi ogni volta a fare certificati, impostare etc etc Però leggendo la documentazione dice: "This example should only be used for testing on the local network because it uses a unencrypted http connection. When you want to have your server reachable from the internet adding HTTPS-encryption is mandatory! " Quindi essendo interno non avrebbe molto senso no? | 11:19:08 |
| Michelangelo | si e no, alla fine basta importare a mano il certificato sul client (windows o linux che sia) | 11:20:04 |
| Michelangelo | è come fidarsi di come vengono cablati i cavi in casa, se viene fatto da soli ovviamente ci si deve "fidare di se stessi" | 11:20:33 |
| Michelangelo | in pratica non c'è un ente di certificazione tra il server e il certificato stesso, quindi è valido finchè lo ritieni valido te. chiaramente se lo usi internamente la certificazione è inutile, quindi non ci sono rischi o altro | 11:23:38 |
| Mark | No quello l'avevo capito benissimo | 11:24:26 |
| Michelangelo | il discorso cambia se invece vuoi usarlo per collegarti da fuori casa/ufficio, in quel caso non và assolutamente usato perchè è facilmente aggirabile da malinzentionati | 11:24:29 |
| Mark | Sono qui sul mio PC di casa ad uso mio personale interno e non esposto ad altre persone. Visto che non mi interessa renderlo sempre online e accessible all'esterno mi domandavo se fosse necessario o meno | 11:25:23 |
| Michelangelo | necessario no | 11:25:49 |
| Mark | Diciamo che l'unico modo sarebbe quella di conoscere la mia passw del wifi e avviare la macchina con i permessi di admin | 11:25:50 |
| Mark | Ma in quel caso sarebbe compromessa tutta la rete | 11:26:08 |
| Michelangelo | esatto e ovviamente renderebbe inutile qualunque certificato da browser | 11:26:42 |
| Michelangelo | alla fine l'https serve su servizi esterni o per pura sicurezza aggiuntiva, non è necessario per l'uso esclusivo interno | 11:28:44 |
| Mark | Infatti. Ho una domanda velocissima. E ti ringrazio per la disponibilità. Se decidessi di renderlo accessibile, quindi nginx, ssl ecc. cosa bisogna mettere come VIRTUAL_HOST di nginx? Un dominio in mio possesso acquistato? O anche uno fittizio pincopallo.com ad esempio? Oppure visto che ho l'IP dinamico dovrei mettere il nome del mio DDNS? | 11:29:48 |
| Michelangelo | normalmente si mette l'indirizzo vero (quello con cui ti colleghi) che viene segnato dentro al certificato per l'ssl | 11:31:39 |
| Michelangelo | tipo affarimiei.duckdns.org oppure affarimiei.ddns.com etc etc | 11:32:33 |
| Mark | Ok, quindi dovrei mettere il mio IP o DDNS. In modo che se faccio affarimiei.duckdns.org:8080 punto direttamente al mio server Nextcloud | 11:33:19 |
| Mark | * Ok, quindi dovrei mettere il mio IP o DDNS. In modo che se faccio affarimiei.duckdns.org:8080 punto direttamente al mio server Nextcloud | 11:33:39 |
| Mark | O anche semplicemente senza porta nel caso non facessi il port-forwarding | 11:34:25 |
| Michelangelo | si ma in quel caso invece di farti un certificato da solo, puoi usare una docker per autogenerarli e quindi renderli certificati, tipo questa https://docs.linuxserver.io/general/swag | 11:34:44 |
| Michelangelo | In reply to Mark
O anche semplicemente senza porta nel caso non facessi il port-forwarding quello dipende dalla porta che usi nella docker, la 80 e la 443 sono implicite, tutte le altre vanno scritte nell'indirizzo se non fai un redirect tramite backend, nginx nel tuo caso | 11:35:38 |
| Michelangelo | oppure questa come docker https://nginxproxymanager.com/setup/ | 11:36:35 |
| Michelangelo | la prima è praticamente tutto da console, la seconda ha una sua interfaccia web, poi usano entrambi nginx e certbot per fare redirect e certificati | 11:37:25 |
|  CitiK joined the room. | 21:28:17 |
