Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Even Akamai screws up their SSL certs

akamai.com

Post reply on HN
Print view View original

21–30 of 36 posts

Re: Even Akamai screws up their SSL certs

#21

Post by hercynium »

chuckles

This isn't a SSL cert screw-up, but certainly a silly misconfiguration. They should certainly have known better than to let that happen.

To be fair... when I worked there, I thought about different ways to transparently enable SSL across all domains using a CDN that would work with all existing SSL-enabled browsers and it's a freakin' hard problem. There are potential solutions, but they're not particularly cheap or simple given the IPv4 address crunch and for Akamai even more so since the edge servers are so widely distributed.

Bottom line - I never pitched the idea anyway because while I was interested in making the internet a better place, I knew that it was DOA at Akamai because they're much more interested in making it a more profitable place, and I couldn't think of a strong-enough business case...

Re: Even Akamai screws up their SSL certs

#22

Post by patcheudor »

mnordhoff wrote: post #18
patcheudor wrote: post #7

Better yet, where they absolutely mean to use HTTPS they sometimes use weak keys and ciphers and get an "F" from the Qualys SSL Labs tool. Blogs.akamai.com isn't the only place this happens: https://www.ssllabs.com/ssltest/analyze.html?d=blogs.akamai....

Not the biggest crisis. Okay, they have several awful cipher suites enabled, but no sane client would ever use them. The client report shows that almost every client uses AES; a couple crappy ones use RC4 or 3DES. They don't have PFS, either. That's bad, though unfortunately still common. As far as I know Akamai's position is that the (small) performance cost of PFS is unacceptable. They would be delighted if it was…

All great points. The biggest issue I see with their apparent lack of consideration towards a passable SSL/TLS configuration is that it extends outside of their own corporate web space to impact their customers. As just one example:

https://www.ssllabs.com/ssltest/analyze.html?d=ozsale.com.au

You'll see in the Qualys report that the Akamai accelerated Ozsales gets an "F" & from the Qualys report you'll note that results in a PCI compliance failure (near the bottom of this report):

https://www.ssllabs.com/ssltest/analyze.html?d=www.ozsale.co...

Re: Even Akamai screws up their SSL certs

#23

Post by tantalor »

dsl wrote: post #11

This happens with almost any Akamai'zed domain, if you drop https:// in front of it you get the shared Akamai cert. Customers that pay for SSL get their own pool of IPs that respond with only their cert. Same thing happens with any shared web host that happens to listen on SSL.

So Akamai couldn't afford to pay themselves for their own IP pool and SSL cert? Poor guys.

Re: Even Akamai screws up their SSL certs

#24

Post by tantalor »

hercynium wrote: post #21

chuckles This isn't a SSL cert screw-up, but certainly a silly misconfiguration. They should certainly have known better than to let that happen. To be fair... when I worked there, I thought about different ways to transparently enable SSL across all domains using a CDN that would work with all existing SSL-enabled browsers and it's a freakin' hard problem. There are potential solutions, but they're not particularly…

It might compete with their current, which bundles SSL with dedicated, static IPs. Although IPv6 should solve that scarcity.

Re: Even Akamai screws up their SSL certs

#25

Post by breser »

Mindless2112 wrote: post #3

Only partly related: Most websites don't get proper certificates for their FQDN -- even Google [1]. That, to me, is screwed up. [1] https://www.google.com./

I think Firefox is actually wrong. They do have long standing open bug on this with a lot of, in my opinion, nonsensical arguments. [1]

RFC 6125 [2] says that DNS-IDs should be fully qualified domain names and points you at RFC 1034 [3] for a definition (which doesn't have a definition sadly).

RFC 1034 does specify the difference between complete (or absolute) domain name and a incomplete (or relative) domain name, with complete domain names including the trailing dot. As best as I can tell the first use of Fully Qualified Domain Names (FQDN) came from RFC 1535 [4]. It doesn't really define the term either but proceeds to use it and mentions "absolute 'rooted' FQDN" in such a way that it implies that absolute is adjective. Finally, we get to RFC 1594 section 5.2 [5] which tries to clear up the matter and describes a FQDN in a way that would seem to agree with your usage (requiring the trailing dot), while giving examples that omit the trailing dot. The Wikipedia article on FQDN [6] says otherwise that the trailing dot is necessary. So at best the definition of FQDN is ambiguous in my opinion which means the RFCs don't help us much here with determining the proper way of handling the trailing dot with respect to PKIX certificate validation.

However, I think that there are some conclusions we can draw using some common sense and thinking about the implications of the behavior.

1) Hostnames are commonly used without the trailing dot. As long as they only are missing the trailing dot they are still fully qualified. They may not be absolute and are still relative to the root.

2) Nobody issues certificates with the trailing dot in the common name. It doesn't make much sense for the RFC to be defined in a way that is entirely incompatible with the existing certificates. Especially since it went to such an effort to define how to deal with the old Common Name sytle and not only the newer SubjectAltName style.

Maybe they should have been using absolute hostnames in order to allow everyone to distinguish between certificates that were issued for relative domains but they don't. In general I don't think CAs should be issuing certificates for relative domains.

Mozilla's own CA Certificate Inclusion Policy [7] disallows certificates being issued that are not absolute domains. It does so by saying "the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate." I can't fathom how issuing a certificate based on a relative domain say "www" could ever be compliant with that.

3) What's the worst that could happen if you allow a match on "www.example.com." to the certificate with "www.example.com" in the CN or SNA? Well not much because the trailing dot forces you to the absolute hostname which happens to be what the CA issued the certificate for.

You can't (assuming a search domain of "example.org") ever end up at "www.example.com.example.org" and therefor be matching the wrong domain because of the trailing dot tells the resolver not to do that. If a browser does do that then they have a separate bug.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=134402 [2] http://tools.ietf.org/html/rfc6125 [3] http://tools.ietf.org/html/rfc1034 [4] http://tools.ietf.org/html/rfc1535 [5] https://tools.ietf.org/html/rfc1594#section-5 [6] http://en.wikipedia.org/wiki/Fully_qualified_domain_name [7] http://www.mozilla.org/en-US/about/governance/policies/secur...

Re: Even Akamai screws up their SSL certs

#26

Post by dsl »

tantalor wrote: post #23
dsl wrote: post #11

This happens with almost any Akamai'zed domain, if you drop https:// in front of it you get the shared Akamai cert. Customers that pay for SSL get their own pool of IPs that respond with only their cert. Same thing happens with any shared web host that happens to listen on SSL.

So Akamai couldn't afford to pay themselves for their own IP pool and SSL cert? Poor guys.

The customer portal is at https://control.akamai.com/

www is literally just a sales site.

Re: Even Akamai screws up their SSL certs

#28

Post by chrismorgan »

Buge wrote: post #16
Mindless2112 wrote: post #3

Only partly related: Most websites don't get proper certificates for their FQDN -- even Google [1]. That, to me, is screwed up. [1] https://www.google.com./

I don't think it's possible to buy a certificate with a dot at the end, so I don't see how this is Google's problem. It seems to be either a problem with Firefox or with the domain name system in general. It looks like the problem should be fixed in 2016 because then all non-FQDN certificates will have expired. Then browsers can go ahead and assume that google.com. in a url is the same as google.com in a certificate.

> I don't think it's possible to buy a certificate with a dot at the end,

Citation needed.

Re: Even Akamai screws up their SSL certs

#29

Post by slipangel »

agwa wrote: post #2

Actually, they probably don't intend for people to use www.akamai.com with HTTPS. If you add an override for the bad cert, you end up getting redirected to a non-HTTPS site anyways. I don't see anything like a login link on www.akamai.com so this is probably OK. (Of course it would be nice if everything were HTTPS...)

The a248 cert is used for all SSL requests for properties delivered over Akamai's non-ssl network. It's useful to be able to serve SSL requests even if the cert doesn't have a the hostname in question on it.

Regarding the cipher sneering below: Akamai's default settings probably err on the side of acceptance. Not all of their customers are Amazon.coms - mom & pop ecommerce are unlikely to do anything that would cause a visitor's SSL connection to fail, and changing the ciphers back to the high-acceptance settings would increase their cost of implementation per cert. I'm guessing they manage more than a few of those.

Re: Even Akamai screws up their SSL certs

#30

Post by tmx »

mnordhoff wrote: post #18
patcheudor wrote: post #7

Better yet, where they absolutely mean to use HTTPS they sometimes use weak keys and ciphers and get an "F" from the Qualys SSL Labs tool. Blogs.akamai.com isn't the only place this happens: https://www.ssllabs.com/ssltest/analyze.html?d=blogs.akamai....

Not the biggest crisis. Okay, they have several awful cipher suites enabled, but no sane client would ever use them. The client report shows that almost every client uses AES; a couple crappy ones use RC4 or 3DES. They don't have PFS, either. That's bad, though unfortunately still common. As far as I know Akamai's position is that the (small) performance cost of PFS is unacceptable. They would be delighted if it was…

> no sane client would ever use them

Unfortunately, that's not the case. From RFC 5246:

  Note: some server implementations are known to implement version
  negotiation incorrectly.  For example, there are buggy TLS 1.0
  servers that simply close the connection when the client offers a
  version newer than TLS 1.0.  Also, it is known that some servers will
  refuse the connection if any TLS extensions are included in
  ClientHello.  Interoperability with such buggy servers is a complex
  topic beyond the scope of this document, and may require multiple
  connection attempts by the client.
An attacker that can insert themselves between client and server can cause a negotiation failure - causing the client or server to negotiate a weaker protocol/cipher combination - so its still important to disable weak cipher suites on the server, especially with browsers as old as IE 6 or 7 still kicking around.
Post reply on HN