> 1. If the connection is encrypted, the connection is encrypted.

Hawgwash. Different encryption algorithms have widely varying strengths.
The implementation of encryption can also be flawed. The configuration of
the encryption can be flawed. I suggest that you read the patch logs for
OpenSSL implementations.

> MITM attack ... unlikely in the extreme for a random hotel user wanting
> to access the internet.

Oh? And you know this how? Do you check? Do you know how-to check?

> Or am I misunderstanding something about how these MITM appliances work?

I believe that you misunderstand. They are essentially plug & play devices.

> I tried running IBM.com through that tester website you mentioned,
> and it got an "A" grade.

Great news! Less than 10 days ago, IBM earned an 'F' because it allowed client
initiated renegotiation and insecure renegotiation. I sent an anonymous email
with details. That's mighty fast work for a behemoth.

> I'm not saying SSL/TLS are perfect

re: SSL ... Understatement of the Year
re: TLS ... solved a lot of SSL problems, but faaar from perfect. Still too
easy to screw-up the implementation ... and deliver/force poor security
onto the users.

> ... they have been around for a long time and are pretty well understood.

By researchers, yes. Based on the network/server scans ... waaay too
many sysadmins and network admins are apparently uncaring, unmotivated
idiots.

> For the average user who wants to check his bank account from a hotel,
> I'd have no trouble saying that using https is more than adequate protection.

We disagree.

Joe Sixpack has no way to know or check. If they are using TD Bank,
TransUnion, Schwab, Yahoo, etc ... the security of their SSL connection
is poor.