NMC2 firmware enhancement request for HTTP->HTTPS redirect

[Terry_Kennedy_apc]

On all of the older hw02 products, if HTTP is not enabled (and HTTPS is), browsing to the device's HTTP page returns:

Protected Object. 
This object on the APC Management Web Server is protected and requires a secure socket connection.
Click here to use a secure connection.

On the NMC2 (hw05) products, browsing to the devices HTTP page returns:

Protected Object
This object on the  APC Management Web Server is protected.

In a future firmware release, could that page be changed to include a link to the device's HTTPS page as is done on the older cards? If so, it will be important to either replicate the hw02 functionality (the redirect URL contains card's IP address) or to always go to the FQDN form of the hostname as configured on the card. Otherwise (assuming the card has an SSL certificate issued to device.example.com), browsing to http://device (without the FQDN) will redirect to https://device and generate a "The security certificate presented by this website was issued for a different website's address." or similar error, since the certificate is issued for the FQDN and the user's browser is using the short-form name. I suspect that is why the hw02 implementation always redirects to the IP address.

Note that this is a cross-platform issue (UPS, PDU, ATS, etc. - anything that uses the NMC2 hardware).

[BillP]

Hi Terry,

They had removed this for security reasons. When NMC2 came out, we had a lot of questions on it but the reason is that with the link there on the HTTP page, it gives the user the direct link and configured port number to get to the HTTPS page and that is why we felt it was a security issue and not a good idea to put a hyperlink on the HTTP page since it could get a malicious user that much going closer to gaining access. I can ask about it again but I don't think the opinion has changed unless you can give me any ideas why it wouldn't be a security issue. 

[Terry_Kennedy_apc]

I'm not sure I follow this - if bad guys are able to access http://device.example.com (even to get the page they see now), they can just try https://device.example.com, assuming the device is configured to use the default port. And it is probably a bad idea to have these devices accessible from the whole Internet, anyway.

How about this, which would actually improve that sort of security: Instead of having checkboxes for HTTP, make it 3-choice radio buttons, with the following options: a) no response (don't listen to the port and don't serve any pages), b) simple error page (the current behavior), or c) Error page with redirect to HTTPS. There probably isn't any reason to have an error or redirect page if the user tries HTTPS and it is disabled, since the user would have previously needed to enable HTTPS and install a certificate, which would be rather silly just to tell people to use HTTP.

The existing canned response on the HTTP port discloses that the device is an APC / Schneider management card, and the major version can be inferred by whether the user sees the blue or green page. That is enough that if an exploit against the firmware is disclosed, it is trivially easy to scan the whole IPv4 address space and find APC devices.

And, by the way, the NMC2 web server will serve content out of its images directory to logged-out HTTP users when HTTP is disabled. For example, http://device.example.com/images/good.gif, which is not used in the error page. The NMC2 does protect its other pages from logged-out users. However, it might be possible to infer more information than the fact that it is an APC card and the major version (which the default error page easily reveals) by seeing if a particular image exists in that directory.

[voidstar_apc · Accepted solution]

If I had to guess, I think the concern is that redirecting from HTTP to HTTPS would only offer protection from passive attackers. Active ones can sit in between and keep the connection at HTTP. Not doing the redirect doesn't directly protect against this: attackers could still intercept the HTTP connection and proxy it to HTTPS, however if HTTP ordinarily doesn't work, hopefully nobody would be making an HTTP connection in the first place.

That said, a friendlier option is to use a permanent redirect so the browser autocompletes with the https:// version.