Comment 7 for bug 1822751

A more recent scan of a cloud (Bionic, Queens, latest charms) resulted in a slightly better result, naming just two cookies that don't have the 'secure' flag set.

The output from the scan:

DESCRIPTION:
Secure is an additional flag included in a Set-Cookie HTTP response header. Using the Secure flag when generating a cookie helps mitigate the risk of interception of cookies sent over encrypted
communications, as otherwise they could be accessed outside of the Secure session. If the Secure flag is set on a cookie, then browsers will not submit the cookie in any requests that use an unencrypted HTTP connection, thereby preventing the cookie from being trivially intercepted by an attacker monitoring network traffic. If the Secure flag is not set, then the cookie will be transmitted in
cleartext whenever the user visits any HTTP URLs within the cookie's scope. An attacker may be able
to induce this event by feeding a user suitable links, either directly or via another web site. Even if the domain which issued the cookie does not host any content that is accessed over HTTP, an attacker may be able to use links of the form http://example.com:443/ to perform the same attack.
Note: The team found that all authorisation session cookies were configured securely.
EVIDENCE:
The following shows the cookies being set on OpenStack:
Set-Cookie: login_region="https://<keystone-url>:5000/v3";
expires=Thu, 21-May-2020 11:39:33 GMT; Max-Age=31536000; Path=/
Set-Cookie: login_domain=<domain>; expires=Thu, 21-May-2020 11:39:33 GMT; MaxAge=31536000; Path=/
AFFECTS:
The following host(s)/area(s) are affected:
• Openstack Cookies
o login_region
o login_domain