The other side of the moon

It's been a while since my last two posts on the topic. This time it's Groupon.

The password reset page is over HTTP:

The reset password email that you receive contains a link that looks like this:

http://groupon.com/users/password_reset/{token}?utm_source=password_reset \
    &utm_medium=email&sid={sid}&user={uid}&date={YYYYmmdd}

This link does a 301 to itself and then a 302 to a HTTPS version of itself.

The good thing is that your new password is sent over SSL. The bad thing is that your reset token is sent in clear text.

Update: This issue has been fixed by Groupon a couple of hours after reporting it.

So it looks like I've been forgetting a lot of my passwords recently. After yesterday's issue with delicious submitting passwords in the clear, today I have a problem with livemocha.com.

As before, their login page is properly secured, but the password reset page is over HTTP:

This is the password reset page:

And this is the URL the passwords are POSTed to, in clear text:

They also include third party code on their page, in this case it's a flash object from userplane.com, google analytics, and some JavaScript from pbc.com (alias for paybycash.com)

I've gotten in touch with them via their online form. Let's hope they respond.

I recently tried to log in to my delicious.com account, and realised that I'd forgotten my password, so went through the reset password flow. This is what I saw...

1. The Sign-in page is over SSL, which is good:
   
2. The Forgot password page, where you enter your username is also over HTTPS. Not strictly required, but good all the same:
   
3. This sends you an email with a link to reset your password. This page is not over HTTPS:
   
4. And submitting this form also goes to a page that is not over HTTPS:
   

Now they put the login page on HTTPS, which shows that they want to protect the user's password from sniffing, but the password reset form, which also accepts the user's password, sends the password in clear text over HTTP. This isn't good. If you're going to protect passwords via SSL, do it everywhere. FWIW, the userid (but not the username) is also sent in this form.

Additionally, the password reset page contains JavaScript from google analytics and chartbeat. As I've written before, you shouldn't trust third party scripts. While you may choose to ignore this on most pages, pages that accept the user's credentials should be considered sacred. The user assumes that anything they enter on this page is available only to your servers. By including third party JavaScript, you're breaking that trust.

I've emailed violations@delicious.com with these details, and am awaiting a response.

Update 2012-01-25 21:08 UTC: As of this time, Delicious have fixed the core issue of the password reset page being on HTTP. Kudos to the team for acting quickly. The secondary issue of third party scripts on this page still remains, but that's a policy decision for them, and not me.

Watching the twitter feed about #jsconf shows a lot of people tweeting about #poopin. Turns out that someone's been stealing twitter cookies using a firesheep like tool and tweeting on their behalf. The tweets aren't malicious in nature, and are geared more at educating the user about the need to use SSL or some kind of encrypted tunnel when tweeting over untrusted wireless connections.

Here's the problem. Even people who do know the risks, and take the trouble to use twitter over SSL will get caught because of certain bugs with twitter's handling of their SSL pages.

If you visit https://mobile.twitter.com/, this is what you'd get: (shown in a browser so I could hilight the URL bar)

Click Sign in and this is what you get:

Sign in, and this is what you get:

Notice that the post sign-in URL is no longer https, but is now http.

At various points of time, trying this through my mobile phone, I get redirected from an https site to an http site when I do some of the following:

• Replying to a tweet
• Replying to a direct message (seems to be fixed)
• Retweeting (with/without? JavaScript)

If you search through the page source on https://mobile.twitter.com/ for the string "http://", you'll find a few instances in comments, but then these interesting ones in a JSON object:

"twitterApiBase":"http://api.twitter.com"
"apiBase":"http://api.local.twitter.com:9000"
"twitterBase":"http://twitter.com"
"mobileBase":"http://mobile.twitter.com"

I haven't examined the code in detail to see how these are used, but it seems to suggest that at least some calls are going out over http, and since they're all on the twitter.com domain, your twitter cookies get sent along.

Now this is only the twitter mobile website. Mobile clients could be another matter, and the desktop site could also have problems. I haven't tested. Personally, I try to either use a VPN, or only tweet using SMS, but I have been caught by something like this before (at FOSS.IN/2010) which is when I started to study the problem.

Also, it doesn't matter if you've configured twitter to always use HTTPS. It still has this problem.

I was speaking with my dad on Skype yesterday when he told me that his mails weren't getting sent out, they were all stuck in his mail queue. Now before we go on, it's important to understand the outgoing mail set up.

My dad's machine has fetchmail fetching mail from various POP3 servers and sorting them into each user's mail spool, and it has sendmail to send mail using gmail's SMTP servers. This is perfectly okay, since my dad uses gmail.

Now if you go through gmail's configuration documentation, they say that you need SMTP over SSL on port 587 with TLS. They also say to use smtp.googlemail.com, but we'll ignore that, because we're not in the UK.

Setting this up requires a few simple steps.

1. First, create your sendmail certificate:

         cd /usr/share/ssl/certs
         make sendmail.pem
   

   Note that you can run make usage in this directory for help. Also this directory is created by the openssl package, so make sure you have that.
2. Next, define the SMART_HOST as esmtp:smtp.gmail.com and add certificate paths:

         define(`SMART_HOST', `esmtp:smtp.gmail.com')dnl
         define(`CERT_DIR', `/usr/share/ssl/certs')
         define(`confCACERT_PATH', `CERT_DIR')
         define(`confCACERT', `CERT_DIR/ca-bundle.crt')
         define(`confCRL', `CERT_DIR/sendmail.pem')
         define(`confSERVER_CERT', `CERT_DIR/sendmail.pem')
         define(`confSERVER_KEY', `CERT_DIR/sendmail.pem')
         define(`confCLIENT_CERT', `CERT_DIR/sendmail.pem')
         define(`confCLIENT_KEY', `CERT_DIR/sendmail.pem')
   

3. Now add PLAIN and LOGIN to confAUTH_MECHANISMS so that it looks like this:

         define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 PLAIN LOGIN')dnl
   

   This requires the Cyrus SASL library, which you probably already have
4. You also need to create an auth-info file that looks something like this:

         youraddress@gmail.com
         youraddress@gmail.com
         yourgmailpassword
         smtp.gmail.com

   Make sure this file is only readable by root.
5. Now regenerate everything and start sendmail. On RedHat based systems, this is as easy as running /etc/init.d/sendmail restart. On other systems you may have to run make first (or you may not have to use sendmail at all :)

If all went well, you should now be able to send mail using gmail's SMTP server.

Unfortunately, all doesn't go well. Mails don't go out, and in /var/log/maillog, you get errors saying "smtp.gmail.com: No route to host". You can try a traceroute and a ping, and they'll both succeed.

The problem is with that port 587 thing. For whatever reason, sendmail keeps trying port 25 even though 587 is the specified mail submit port, and sometime in the last few days or weeks, gmail stopped accepting mail submits on port 25 (at least that's what it looks like).

So, get back to your config file. This time I didn't know what options to use, but I know more or less what the sendmail.cf syntax means, and how to edit that file, so I edited it directly.

I went down to the line that starts with Mesmtp, and looked for the line below that which said TCP $h, which basically means connect using TCP to the host specified in $h. We need to add the port to this line. Change the line to TCP $h 587 and we're done.

Restart sendmail, and all works.

But this isn't a good solution, because the next time you regenerate sendmail.cf from sendmail.mc, your change will be overwritten.

So, what I did next, was go into /usr/share/sendmail-cf and run grep -r '^Mesmtp' *. The result which stood out was the mailer file. Inside that file, I saw that the TCP $h line was being added by the macro ESMTP_MAILER_ARGS, so, I just needed to add this one line after the SMART_HOST:

      define(`ESMTP_MAILER_ARGS', `TCP $h 587')dnl

and we're done. Restart sendmail, and the config changes are permanent. All works, and mails go out.