Installation succeeds, but admin panel not working...

[Svartalf]

Okay, I've managed to get past the initial hurdles, but there's something still busted on this thing. Attempts to log into the admin panel on the server end up producing an attempt to download a .bin file from the server instead of the expected results. What's wrong with this picture?

I've got several customers that would love to have an answer that works as nicely as this one does- if I can't test it out and can't get a clean install, I'm afraid I might have to pass on it, as nice as it is.

[marcmac]

I get this when I enter the url as http://host:7071/zimbraAdmin - change it to https://... and the problem goes away.

Originally Posted by Svartalf

Okay, I've managed to get past the initial hurdles, but there's something still busted on this thing. Attempts to log into the admin panel on the server end up producing an attempt to download a .bin file from the server instead of the expected results. What's wrong with this picture?

I've got several customers that would love to have an answer that works as nicely as this one does- if I can't test it out and can't get a clean install, I'm afraid I might have to pass on it, as nice as it is.

[Svartalf]

Not good. It should NOT be responding on the HTTP port with anything if it's expecting to be on a secure port. Simply put, it should simply refuse service or come back with a BLANK page. That's a nice n' nasty security flaw there.

[schemers]

The server is listening for requests on port 7071, and expects them to be in SSL. If you tell the browser to talk to port 7071, but tell it to use http instead of https, then it blindly will. The server is most likely responding with the SSL handshake, at which point the browser thinks it is getting a binary file.

The server at no time is accepting requests on another port, or not using SSL.

roland

[Svartalf]

Originally Posted by schemers

The server is listening for requests on port 7071, and expects them to be in SSL. If you tell the browser to talk to port 7071, but tell it to use http instead of https, then it blindly will. The server is most likely responding with the SSL handshake, at which point the browser thinks it is getting a binary file.

The server at no time is accepting requests on another port, or not using SSL.

roland

The biggest problem with that thinking is that it shouldn't be doing that- if it's not SSLed, it shouldn't be talking in the first place. If I plug in https://slashdot.org:80 into a browser, it correctly refuses the request. If it honors it, something's NOT configured or coded correctly- period. I know, I happen to have done quite a bit of work on these protocols and what they should/shouldn't do when I worked for epicRealm.

It's a potential security hole that shouldn't be in the first place. You should NEVER accept interactions on a protocol that is not officially being used- it's an invitation to disaster. As a security consultant, this would constitute a no-go for the customer and if they had Zimbra installed with it doing this, I'd be advising that they find some other solution. It's not a good idea, even if "nothing" works with it- witness the GDI WMF exploit for a PRIME example of why you don't think in terms of "it's not being used this way, so it's not a problem..."

[schemers]

You are sending bogus data when you attempt to use the HTTP protcol over a socket that is expecting SSL/TLS.

In particular, the server is expecting a client hello message sent to it. It absolutely *must* be prepared to deal with requests it can not parse. In this case, it is most likely sending back a handshake failure alert. Because the SSL protcol is binary, the browser thinks it is getting back binary data and asks you to save it.

The server is doing exactly what it should be doing! It is not "accepting interactions on a protocol that is not being used", it is returning an error formatted correctly for the protocol that *is* being used.