Comment 29 for bug 1409142

@Dave for the http/https case, you are correct, if you're confident that nova reliably has access to whether or not the current connection is HTTPS on the client side. It's common to run TLS decryption at cloud boundaries so that secrets aren't spread across the cloud. Does nova properly support forwarded headers to determine this state? Does it correctly ignore them when it does not need them?

Re: DNS rebinding and host whitelisting: I see no reason you can't whitelist both IP addresses and the expected domain names if that is the expected customer use case. Browsers still send the HOST header with the IP address if that's what's in the url.

@Tristan: the DNS rebinding issue is correctly mitigated in Horizon because Horizon uses Django, which provides robust protection against this class of attacks. Nova's adhoc reinvention of these mechanisms is what got us in trouble here.

@Tristan: we need to fix the http/https thing more urgently than we need to fix the dns rebinding thing. Both issues will become public when this bug becomes public, but the http/https thing is trivially exploitable. If we keep this bug private, we'll need to issue a followup patch and CVE shortly - I'm ok with that, but not linking to the public launchpad bug will encourage people to look more closely at the patch.

The DNS rebinding issue is less critical, though I suspect you'll find people are happy to demonstrate an exploit the moment you claim something isn't a problem.

As the current patch stands, it's not wrong, just incomplete. If you'd prefer I open new issues for these things, I'll do that and we can treat them separately.