HTTPS, SSL, 443
awaddell says:
Hi, I posted on this subject in the Gmail forum a couple of days ago but no replies so here goes #2
I have gmail configured to use SSL ubiquitously. This is essential outside of a controlled VPN environment - imo.
I'm using FF3 with the RTM addon.
If I were to load RTM from Gmail, the HREF is canonicalised to
http://www.rememberthemilk.com/login/?gmail=1
there's no way it seems to affect this which means I cannot trust my staff (or my mother say) to *not* head off on a path that has them sending their RTM credentials in the clear (which will then be available to every idiot ISP, dirtbag WiFi eavesdropper or whatever). People re-use passwords across multiple applications and that's the real issue (for me). Other people may care about the confidentiality of their RTM data.
So, OK I can login into RTM with https first and then load gmail but 'this does not scale/this is not a workable use-case'.
Here's another gotcha
If you login with (forced) SSL via https:// and typo your password, then RTM switches the protocol back to http://
http://www.rememberthemilk.com/login/?tryAgain
^^^^
This is really nasty folks - not just because the protocol should be transparent to the application but because this will really trip people up.
Security is paramount. Not, in my case because of the nature of the data we're storing with you but because passwords are typically re-used in other, perhaps more data-critical applications.
I think you need to offer a similar option to what google does and let the user decide if they want to use SSL everywhere. I guess the iframe on the gmail page is being added by the addon so the addon will need to/ need to know to change the proto to https. This may require a simple addon 'preferences' option (make it the user's problem to organise but do give them the option)
As you can see, security is a deal breaker for me. As it should be imo. Of course there's a cost in terms of processing both for you and for me. As I commented in my original post - port 80 is the world's digital toilet and more so every day. There's a price of admission to be paid for using port 443 but some people like me don't mind the price for the superior outcome (which should be *completely negating security issues relating to data in transit*).
PS Of the list of over 100 task management apps I quickly browsed through (somewhere) most are hopelessly clueless (only runs on windows - groan/ do everything on our website - groan). I believe in the model you're using which means I don't mind fighting you over this issue but I do hope that I 'win' and that you take the issue of security seriously enough to make it go away.
Regards,
I have gmail configured to use SSL ubiquitously. This is essential outside of a controlled VPN environment - imo.
I'm using FF3 with the RTM addon.
If I were to load RTM from Gmail, the HREF is canonicalised to
http://www.rememberthemilk.com/login/?gmail=1
there's no way it seems to affect this which means I cannot trust my staff (or my mother say) to *not* head off on a path that has them sending their RTM credentials in the clear (which will then be available to every idiot ISP, dirtbag WiFi eavesdropper or whatever). People re-use passwords across multiple applications and that's the real issue (for me). Other people may care about the confidentiality of their RTM data.
So, OK I can login into RTM with https first and then load gmail but 'this does not scale/this is not a workable use-case'.
Here's another gotcha
If you login with (forced) SSL via https:// and typo your password, then RTM switches the protocol back to http://
http://www.rememberthemilk.com/login/?tryAgain
^^^^
This is really nasty folks - not just because the protocol should be transparent to the application but because this will really trip people up.
Security is paramount. Not, in my case because of the nature of the data we're storing with you but because passwords are typically re-used in other, perhaps more data-critical applications.
I think you need to offer a similar option to what google does and let the user decide if they want to use SSL everywhere. I guess the iframe on the gmail page is being added by the addon so the addon will need to/ need to know to change the proto to https. This may require a simple addon 'preferences' option (make it the user's problem to organise but do give them the option)
As you can see, security is a deal breaker for me. As it should be imo. Of course there's a cost in terms of processing both for you and for me. As I commented in my original post - port 80 is the world's digital toilet and more so every day. There's a price of admission to be paid for using port 443 but some people like me don't mind the price for the superior outcome (which should be *completely negating security issues relating to data in transit*).
PS Of the list of over 100 task management apps I quickly browsed through (somewhere) most are hopelessly clueless (only runs on windows - groan/ do everything on our website - groan). I believe in the model you're using which means I don't mind fighting you over this issue but I do hope that I 'win' and that you take the issue of security seriously enough to make it go away.
Regards,
awaddell says:
Update:
I posted that forum message after loggin in with HTTP as
https://www.rememberthemilk.com/forums/help/newtopic.rtm
On submitting the form, RTM rewrote the protocol as
http://www.rememberthemilk.com/forums/help/
I think you need to dig deep in your classes to remove all canonicalisation and replace with $PROTO which is available in the SERVER environment (or more securely with EGPCS if using PHP).
Regards, (as I tcpdump this port 80 traffic for my throwaway password)
I posted that forum message after loggin in with HTTP as
https://www.rememberthemilk.com/forums/help/newtopic.rtm
On submitting the form, RTM rewrote the protocol as
http://www.rememberthemilk.com/forums/help/
I think you need to dig deep in your classes to remove all canonicalisation and replace with $PROTO which is available in the SERVER environment (or more securely with EGPCS if using PHP).
Regards, (as I tcpdump this port 80 traffic for my throwaway password)
awaddell says:
test again - forgot to start tcpdump ;-)
emily (Remember The Milk) says:
Hi awaddell,
Security is very important to us. Regardless of whether the login form is accessed at the HTTP or HTTPS URL, login details are always encrypted (the form always posts to HTTPS, so login details are never sent in the clear).
If you access Gmail via HTTPS, RTM for Gmail will both send your login details and your tasks data over HTTPS. (Sorry the login URL is confusing for Gmail.)
Thanks for reporting the issue when a user's login fails at the HTTPS URL and they're sent back to HTTP rather than HTTPS. In that case, their login details are still sent via HTTPS, but the application is loaded via HTTP (which isn't desired as by accessing the HTTPS URL initially they obviously wanted to load the application via HTTPS too). We'll get this corrected.
We're looking into the possibility of providing an option to always use SSL when loading the application (like Gmail recently introduced). Unfortunately we can't guarantee that when accessing the main site (not the application) via HTTPS, that all links will use HTTPS (as some parts of the site, such as the blog, aren't available via HTTPS). However, having an option like Gmail does would ensure that if a user always wanted to access the application via HTTPS, they would always be forced into that mode.
Security is very important to us. Regardless of whether the login form is accessed at the HTTP or HTTPS URL, login details are always encrypted (the form always posts to HTTPS, so login details are never sent in the clear).
If you access Gmail via HTTPS, RTM for Gmail will both send your login details and your tasks data over HTTPS. (Sorry the login URL is confusing for Gmail.)
Thanks for reporting the issue when a user's login fails at the HTTPS URL and they're sent back to HTTP rather than HTTPS. In that case, their login details are still sent via HTTPS, but the application is loaded via HTTP (which isn't desired as by accessing the HTTPS URL initially they obviously wanted to load the application via HTTPS too). We'll get this corrected.
We're looking into the possibility of providing an option to always use SSL when loading the application (like Gmail recently introduced). Unfortunately we can't guarantee that when accessing the main site (not the application) via HTTPS, that all links will use HTTPS (as some parts of the site, such as the blog, aren't available via HTTPS). However, having an option like Gmail does would ensure that if a user always wanted to access the application via HTTPS, they would always be forced into that mode.