Se i dati non abbandonano mai il sistema, probabilmente non c'è alcun vantaggio nell'usare SSL per proteggere i dati trasmessi. Ma vedo altri problemi con il tuo approccio:
It has a local web server that supplies a management console for a product we use
Questo suggerisce di accedere alla console di gestione con un browser Web sul sistema locale. A meno che non ci sia un modo per limitare il browser solo a questo host, devi stare molto attento agli attacchi come CSRF, che possono essere attivati se visiti altri siti con lo stesso browser. Questo è un tipico vettore di attacco per console di gestione basate sul web e sarete sorpresi di quanti router o firewall siano vulnerabili contro questo tipo di attacco.
E anche con questa restrizione, le azioni di gestione indesiderate potrebbero essere attivate dai registri in visita o da altri file sulla console di gestione, a meno che non si sia stati molto cauti nell'escludere l'input dell'utente per sconfiggere gli attacchi utilizzando l'iniezione di script o le iniezioni HTML (come XSS). p>
Probabilmente è anche facile accedere alla console da remoto facendo esplicitamente il port forwarding (usando putty o prodotti simili). Questo è comunemente usato per i sistemi di controllo remoto, anche se il fornitore stesso si è esplicitamente assicurato che l'accesso remoto non è possibile nell'impostazione predefinita per motivi di sicurezza. È fatto perché questo tipo di restrizione è spesso più visto come un fastidio e il rischio viene ignorato.
Firewalls have blocked off access to the management console for all external systems.
Se questa protezione viene eseguita solo da firewall, è necessario ricontrollare il design. Di solito è meglio avere il server in esecuzione solo su un indirizzo IP che non può essere raggiunto dall'esterno in base alla progettazione, ad es. localhost (127.0.0.1). In questo caso non sarebbe necessario un firewall per limitare l'accesso e c'è una cosa in meno che può andare storta.