SSL Configuration for Internal (LAN) Traffic

[awdspyder 11]

First, let me preface this post by saying I have no intention of opening up Emby to the outside.  If I ever wanted to access remotely I'd leverage a site-to-site IPSec tunnel or SSL VPN client to do so.  That said, I have an internal Windows Enterprise CA, and would simply like to secure Emby with a cert that's not self-signed.  Now, I certainly understand the process regarding SSL implementation described in numerous posts here, but these all imply you wish to allow public access, which I do not.  I may be somewhat of a unique case in this regard.  So my questions are twofold:

 

1) Where does Emby store the self-signed certs for the default configuration in Windows?  The only certs I found are in %userprofile%\AppData\Roaming\Emby-Server\ssl.  If one wanted to replace the self-signed cert with a valid cert, how would one point the application to said cert?  Is there a config file somewhere that can be edited? I didn't know how safe it was to play with the XML in %userprofile%\AppData\Roaming\Emby-Server\config.  If this were IIS/Apache/JKS, etc. it would be straightforward, of course.  

 

2) Netstat clearly shows that internal devices such as Rokus and Android apps are connecting in the clear on the default port of 8096.  In fact the only SSL connections is me, via the browser.  Similar to above, is there a way to force internal traffic to use SSL without checking the "Allow remote connections..." box?

 

I also understand that checking the box for "Allow remote connections to this Emby Server" will expose many of these settings in the admin UI, but as previously stated, I have no intention of allowing remote access. I'm open to checking the feature in the UI and simply not opening the firewall to allow said access, but that seems clunky.  If checking the box really does nothing other than expose these settings, that's a valid workaround and I'll give it a try, but I thought I'd ask first.

 

Thanks!

Edited April 11, 2020 by awdspyder

[rbjtech 5284]

My query would be if this is only going to be used internally, then why bother with SSL at all ?    

[awdspyder 11]

Well, that seems like a somewhat disparaging approach, but fair enough, I'll bite.  The pragmatic response is that I like to practice defense in depth whenever and wherever possible.  I've been in the IT field over 20 years, and the number of attacks I've seen originate inside the network far exceed anything that actually penetrates the firewall.  I've built large web infrastructures that continuously did a thousand http requests/sec and hundreds of Mbps that were never compromised through the ASAs.  The knuckleheads I worked with, OTOH?  All damn day long they presented a risk to the company.  Now, I fully understand I'm not passing credentials that risk exposing PII.  Nor to I anticipate bad actors in my driveway attempting to penetrate my network, though most of us likely do live with knuckleheads when it comes to technology.  So in reality, it comes down to three things:

 

1) It's a good practice (and good practice)

2) I don't like clicking through the warnings in the browser

3) I want to

 

Let's face it - 50TB of local media for Emby isn't exactly necessary to bother with, either.  I guarantee we all know smart people who are like, "Dude, aren't all those movies in the cloud?"  And they're not wrong.  We all commit the time, expense and deal with the idiosyncrasies of these environments because we want to, plain and simple.

Edited April 11, 2020 by awdspyder

[Luke 42085]

Regarding of where it stores, best thing to do is just use the web interface to configure your certificate in the network settings of emby server.

[awdspyder 11]

Thanks, Luke.  

 

Of course the only way to expose those settings in the UI is to check the box entitled, "Allow remote connections to this Emby Server."  Like I said, I'm happy to enable this as a workaround, but I'd like to understand exactly what checking this box does under the hood.  It's titled in such a way that indicates it does more than simply expose the additional settings. 

 

Furthermore, when checking this box I'm not going to supply an external domain, because I'm not going to use one.  However the language in the application explicitly states, "This field is required when used with a custom ssl certificate."  So how do these settings behave when the box is checked but an external domain is not supplied?  Should one simply supply the internal FQDN or DNS name here in this case?

 

Personally, I don't see why one couldn't implement their own certificate without having an external domain.  These are not mutually inclusive things.  Consider a large environment where policy requires all internal services to use SSL (I've worked at many).  This is an edge case for sure, but a valid case nonetheless.  Of course, I'm quite aware that this is likely just a case where there is low demand for such a thing, and thus a low priority for building such a facility into the application, not that it couldn't be done.

 

Thanks!

Edited April 12, 2020 by awdspyder

[Luke 42085]

It was just an oversight because most people who are using SSL are only doing it for remote connections. You can enable it to show the options, configure your SSL, and then disable remote access again.

[awdspyder 11]

Thanks, Luke, works perfectly!  You're the man as always.  I was going to test that very thing to see if some of the settings persisted in the XML, but hadn't gotten around to it.

[Luke 42085]

Thanks for the feedback  !

[rbjtech 5284]

Well, that seems like a somewhat disparaging approach, but fair enough, I'll bite.  The pragmatic response is that I like to practice defense in depth whenever and wherever possible.  I've been in the IT field over 20 years, and the number of attacks I've seen originate inside the network far exceed anything that actually penetrates the firewall.  I've built large web infrastructures that continuously did a thousand http requests/sec and hundreds of Mbps that were never compromised through the ASAs.  The knuckleheads I worked with, OTOH?  All damn day long they presented a risk to the company.  Now, I fully understand I'm not passing credentials that risk exposing PII.  Nor to I anticipate bad actors in my driveway attempting to penetrate my network, though most of us likely do live with knuckleheads when it comes to technology.  So in reality, it comes down to three things:

 

1) It's a good practice (and good practice)

2) I don't like clicking through the warnings in the browser

3) I want to

 

Let's face it - 50TB of local media for Emby isn't exactly necessary to bother with, either.  I guarantee we all know smart people who are like, "Dude, aren't all those movies in the cloud?"  And they're not wrong.  We all commit the time, expense and deal with the idiosyncrasies of these environments because we want to, plain and simple.

 

 

..I too have been in the IT security industry for 30+ years - so a lot of what you say is 'fair enough' but as no doubt you are aware security begins with physical security.  In your own home I would hope physical access is not behind audited physical access, data at rest is not encrypted etc so any internal SSL access is technically useless if I can get physical access to the data....   'I totally get it' and #3 on your above list made me lol and is probably the key factor here.  

 

Glad the issue is sorted now anyway - it good to have these discussions !

Edited April 14, 2020 by rbjtech