Over a month later and Comcast still doesn't know how to SSL | Hacker News Reader

Over a month later and Comcast still doesn't know how to SSL

forums.comcast.com

131 pointsswedegeek49 comments

The SSL certificate expired Tuesday, May 8, 2012.

Pro tip: Set up monitoring alerts on your SSL certs to alert your sys admin when they are getting close.

For example, here's a Nagios SSL expiration alert: http://exchange.nagios.org/directory/Plugins/Network-Protoco...

The standard https check has it built-in with the right flags. Use -h or --help to figure it out. (They provide different output)

That would be

/usr/lib/nagios/plugins/check_http --ssl -C 30 -H contracts.comcast.com

CRITICAL - Certificate expired on 05/08/2012 23:59.

You can also use openssl's built-in utility* to see that the certificate has expired:

  openssl s_client -showcerts -connect contracts.comcast.com:443

*You may also need to specify the path to your certificates using something like: -CApath /etc/ssl/certs/

To get the exact expiration date, it appears you have to do:

1) download cert:

  openssl s_client -connect hostname:port > cert.pem

2) verify date:

  openssl x509 -in cert.pem -noout -enddat

You rock sir. I was on my phone so I couldn't look it up when I wrote the op. Thanks.

Respectable CAs (perhaps that's an oxymoron) will email the contact email address ahead of time warning about the expiration.

Respectable CAs will email you a warning about a month before it expires.

Disreputable CAs will email you 3-4 months before it expires, emphasising that you need to "ACT NOW" (GoDaddy is guilty of this).

And on top of that, any registrar I have ever used sends me email alerts to let me know they are about to expire. A lot like domain names.

It amazes me that these SSL errors stay this way so long. Even google has been guilty of this in the past.

I wrote an application a while ago which would connect to an SSL service and print out how many days until expiry. It works with network ranges and supports IPv6 also. It was designed with the aim of having something useful to stick in a cron job. So if you specify "--expires-within 14" for example, it will only output data for certificates that will expire within the next 14 days. For example:

  mike@alfa:~$ sslScanner.pl contracts.comcast.com news.ycombinator.com smtp.gmail.com:465
                               IP Address   Port  Days Left  Common Name
                             130.94.78.15    443       -172  contracts.comcast.com
                          174.132.225.106    443        934  news.ycombinator.com
                           173.194.78.108    465        222  smtp.gmail.com
                           173.194.78.109    465        222  smtp.gmail.com
              2a00:1450:400c:c00:0:0:0:6d    465        222  smtp.gmail.com
  mike@alfa:~$

You can get it from https://github.com/mikecardwell/sslScanner

It;s been more than a month, perhaps not this particular one, but I have reported to them on twitter multiple times that their SSL certs are dead. Their IP to geolocation is also way off, something they don't seem to care about.

I think the worst was I contacted them on twitter about several hosts that were hammering one of our mail servers, around a million lookups for usernames a day for each domain.

I blocked the IP's, problem solved, but wanted them to nuke the accounts. They said to send in the relevant data. I nicely formatted all the data, snipped sections here and there, and tar'd the files.

Emailed them in and was told they don't know what a tar file is. Sent them in gzip, they can't open them. Finally said screen it and posted the data to pastebin in plain text and sent them the raw link. They didn't know what to do with it.

At some point, I just gave up.

If they can't open a tar, there's a good chance they can't open gzip either. I'd be willing to bet they run Windows on their desktops. Sending it as a Windows-standard zip might have been the better option.

If they didn't know what tar file is, sending any format to that person would be useless - obviously, it's not the right person to talk to on this question, they are not nearly knowledgeable enough. I would guess it's some low-level support that is probably not even allowed to escalate the issue, and is not able to handle it, most they can do is to put the data into some kind of internal database where it quietly dies.

As for the question how to get the right person, I'd like to know a way...

To be fair to Comcast you're running into a few things. In a non-technical kind of way and in no order...

Comcast.com is (stop laughing) a high value domain. You're not likely to get any CA to just hand over a certificate in 2 seconds. It will get flagged for manual inspection and further details will be required.

Large companies like this aren't as simple to handle. If it were a small startup with 3 people you want to bet your pants it would be fixed right away. But I bet you there are e-mails flying around into underpaid mailboxes waiting for a response. Not every corporate office is a well-oiled machine.

But on the flip side it is unfortunate they're struggling with it. The poor front line customer service rep (Carole) has no choice but to assure you they're currently working on it and move on to the next squeaky wheel. Like any person in customer service, her job is to assure you and move on.

After a few years at Ohio State, I disagree with giving Comcast the benefit of the doubt and chalking this up to red tape.

It's pretty funny that an ISP can't get their certs together, but geez, temporarily accept the cert, read the service agreement and get on with your life. Are you seriously worried about a man-in-the-middle attack here?

Trying to impress first tier forum support with your long history with computers isn't helpful to anyone, and sounding off about a serious legal issue in bold and italics is probably just making the lawyers giggle. It's nice to report the problem and follow up on it. There's no reason to be a dick about it.

I agree. To me the story here is that Comcast is a huge company that takes way too long to process simple changes. But in reality, who the fuck cares if the cert for that page expired? It's not like their collecting your bank records.

> but geez, temporarily accept the cert,

That might be acceptable advice on HN, but it's lousy advice for the general public.

For some types of certificate errors, sure. But we're talking about expiration here. You can still check that the certificate was validly issued and (theoretically) that it hasn't been revoked. The certificate is only a year and a half old, compared to the verisign certificate with a 10 year life span that signed it.

I know the warnings are in place for a reason, but why don't the affected people just bypass the warning. There is no reason to think that just because the date changed that Comcast's certificate is now compromised. If the certificate was issued with an expiry date of five years or more, I'd understand not taking the chance; especially considering how long Comcast is taking to review their certificate - if their certificate did become compromised their customers would likely never find out.

I would guess that 99% of users don't know the difference between expired, hacked, bad, or any number of things. They just see "ERROR" and stop dead.

99% of users say "stop bugging me, computer, I just want my site" and click on "ignore warning".

One problem with this is that it trains the user to ignore a security warning which might not be crying wolf next time.

Dude if somebody wants to create a man in the middle attack to see my Comcast contract, that's cool. Hell, just email me and I'll send you a copy. I think context matters. I don't think most people would ignore a cert warning if they were about to do something they deemed private.

I doubt it. Steve Gibson once related how he sold many copies of his software on his website, even when the website accidentally had an invalid certificate. His software is geared towards a tech-savvy audience. If tech-savvy people don't behave securely, why should we expect most people to?

>I know the warnings are in place for a reason, but why don't the affected people just bypass the warning.

Not caring about certificate expiration may be a sign of not caring about other, more serious, security issues.

Corporate bureaucracy often results in bad, strange, or just plain weird circumstances. Film at 11.

Indeed. When a large company has a problem, there are an awful lot of people in that company who aren't empowered to fix it.

A little OT, but using HTTPS Everywhere has shown me how badly SSL is configured on many sites. Default certs for root domain being used on subdomains, scripts and styles loaded over HTTP (and hence blocked by Chrome - by far the most common and most annoying), HTTPS port listened on but no site served, default certs for completely unrelated sites showing up, etc.

Easy solution: stop using HTTPS Everywhere to force HTTPS in cases where the admins aren't supporting it. The admins haven't configured it badly, they've configured it for the cases they want to support. Using an extension to force non-standard behaviour breaks things.

"Force non-standard behaviour"?

If I connect using a protocol to a site, it should work! If said protocol is poorly configured, it shouldn't be available!

Looks like their cert for https://www.comcast.com/ is fine, so this problem is only with the 'contracts' subdomain. I'm guessing that's a low traffic/priority section for them.

They should buy a wildcard cert for *.comcast.com and be done with it.

The "I was using the internet before there was an internet" argument is not helpful to anyone in this situation. The first tier support has no way of verifying the claim and even if they did, they still might not be able to escalate the issue before asking the documented questions. The questions in this case seemed quite sensible, I've been caught out with SSL certs expiring before realising my time wasn't syncing. It's not helpful to the OP because it comes across as arrogant and they're not going to endear themselves to the support agent.

Best for everyone is to remain polite, responsive to the agent's requests (however seemingingly inane) and the process will move a lot quicker.

I thought he was very polite. He made sure everyone was on the same page, thus avoiding a lot of unneeded commentary.

In my personal experience, @ComcastBill, a fellow named Bill Gerth in Ohio(?), has been a responsive and helpful face inside Comcast. On two occasions short, specific queries his way resulted in receiving direct, actionable contact from inside Comcast.

I sent him a tweet about this specific issue, and hopefully he can make this little embarrassment disappear: https://twitter.com/Roadstead/status/262544429490003968

Why do companies buy certs one year at a time?

You can make certs for ten, even twenty years.

This all goes back to the SSL cartel wanting control.

Just make a cert good until January 19, 2038 and get it over with.

Comcast will have to get a valid SSL certs and cannot use a self signed certificate. The longest valid cert I have seen is 4 years.

You usually can't, for several reasons.

Self-signed certs won't fly for public-facing websites.

CAs simply won't issue for more than 3 years, typically. They want to make money, and the easiest way to make more money is to make certificate lifetimes short.

There's an arguable security concern. If a site's cert gets compromised and it's not detected, having a shorter cert lifetime might in some situations prevent the compromise from persisting more than the certificate lifetime. True, if the server is compromised, you can replace certs every year and they'll all be compromised, but if it's a server farm with frequent reinstalls from trusted base media, server compromises won't necessarily persist, and compromised 5+ year website certificates might turn into the weakest link.

If the site must pass periodic scans (for example, by one of those PCI compliance outfits), most of those scanners consider more than 3 years to be "too long" for a cert to be valid. Whether they'd fail the site for that, I don't know.

Ideally, the information in the certificate is vetted by the certificate authority. So, if you have your company name, physical address, and contact info in there, the CA would have actually conducted some checks to make sure that information was correct and not fraudulent before certifying it. That vetting process costs time and money. Unfortunately, nobody can detect whether it has happened so now we have $5 certs that are essentially unvetted (uncertified certificates?) because people are only interested in the encryption component.

It actually expired almost 6 months ago, on May 8.

That happens with my lame credit union all the time.

A month after what? September 27th is what?

Look at the dates on the posts in the thread. He gave them a month before coming back and chastizing them again to find out they'd closed the ticket without fixing it.

This is pretty damn pathetic (1), that's all I can think to even say.

(1) esp given that the cert expired in MAY.

This is a problem that could take up to dozens of dollars to solve, and tens of minutes. Check back in early 2013?

Probably. Never underestimate the bureaucracy of a big corporate entity (specifically when it comes to having to pay money to fix something).

Possible causes:-

   * General ineptitude
   * It's not something they monitor.
   * The main www site is up, what's the problem?
   * The technical contact for the previous certificate is no longer at the company. So the "expiring soon" notification was never received.
   * The PO is awaiting 'approval', or Finance are sitting on it whilst arguing whether it's CapEx or OpEx, or the "Business Justification" was rejected by someone who doesn't understand, etc, etc.

The original post was on 2012-09-21 and still no resolution. Not to mention, as others have pointed out, it's for a cert that expired several months ago. But this link is public acknowledgement of the issue and it's still unresolved as of today. Regardless of bureaucracy, that should be considered highly unacceptable for the largest consumer ISP in the United States.

5 months to be exact :-)

Pretty sad for a company selling internet access to be so naive about basic things.

I love when shit like this happens. Edit: love when it happens to other people.

If you said, "I love when shit like this happens, because I've made the same mistake a million times and it makes me feel better seeing the big players do it" you probably would have even received a few upvotes.

HN doesn't really tolerate straight up mean comments.

duly noted

Reply on news.ycombinator.com