Executive summary

See Joomla! forum post on SSL issues with Joomla! 3.1 The same issue was verified by my client Ryan H. who has also confirmed the fix. Due to the way mod_login works when you have an HTTPS site and enabled mod_login's "Encrypt login form" most browsers will refuse to proceed (posting to unencrypted page from an encrypted page) and those which do allow you to proceed land you in potentially hot water as it's now possible for an intruder to perform a man-in-the-middle attack, completely negating the benefits of using HTTPS on your site. Furthermore, it's a low security issue of its own right as an HTTP site with optional HTTPS and mod_login's "Encrypt login form" set to Yes will result in the form being posted to an unencrypted (HTTP) URL, leaving the login form open to man-in-the-middle attacks.

Technical Explanation

JRoute::_() has a third parameter $ssl which determines how JRoute should handle the resulting URL's protocol. 1 forces HTTPS, 2 forces HTTP and 0 leaves the protocol as it is. However, it doesn't recognise "1" passed as a string parameter. Coincidentally, mod_login passes this parameter as string when you set "Encrypt login form" to Yes. Due to this discrepancy in the code, if you have an HTTPS site and set mod_login's "Encrypt login form" to Yes then JRoute tries to submit the login form to the unencrypted (HTTP) site as $ssl === 1 returns false, making JRoute treat the parameter as if it were 2 (force unencrypted). Big whoops!