How Serious Is James Clapper About Cybersecurity When His Office Can't Even Get Its SSL Certificate Right?
from the just-asking dept
James Clapper and the Office of the Director of National Intelligence (ODNI) have been among the loudest FUD-spewers concerning the "threats" to cybersecurity out there, and the need for massively dangerous "cybersecurity" legislation that would really just open up the ability for the Intelligence Community to get more access to private data. However, security researcher and ACLU guy Chris Soghoian noticed yesterday that the SSL security certificate on the ODNI website isn't even valid:
The Director of National Intelligence (@ODNIgov) can't be bothered install a valid HTTPS cert on their website #cyber pic.twitter.com/iiPIkFEfhD
— Christopher Soghoian (@csoghoian) July 23, 2014
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: cybersecurity, fud, james clapper, odni, ssl
Reader Comments
Subscribe: RSS
View by: Time | Thread
[ link to this | view in chronology ]
Erm..
[ link to this | view in chronology ]
Re: Erm..
[ link to this | view in chronology ]
Re: Re: Erm..
[ link to this | view in chronology ]
Re: Erm..
[ link to this | view in chronology ]
Re: Re: Erm..
and
"This page includes a script from unauthenticated sources."
I'd post a pic but I don't think that is possible on Techdirt. This warning has been on the site since it went SSL.
[ link to this | view in chronology ]
Re: Re: Re: Erm..
And keep in mind that if you use a proxy, it can screw with SSL connections.
[ link to this | view in chronology ]
Re: Re: Re: Re: Erm..
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Erm..
[ link to this | view in chronology ]
Re: Re: Re: Re: Erm..
[ link to this | view in chronology ]
Re: Re: Re: Re: Erm..
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Erm..
[ link to this | view in chronology ]
Re: Re: Re: Re: Erm..
It is the ads that are on plain http connections and causing this issue, though. So if you are viewing the site with an ad-blocker, it should actually come up totally secure.
[ link to this | view in chronology ]
Re: Re: Re: Re: Erm..
[ link to this | view in chronology ]
Re: Re: Re: Erm..
[ link to this | view in chronology ]
Re: Re: Re: Re: Erm..
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Erm..
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Erm..
If you cannot guarentee all the content on the page (however delivered) isn't going to be secure, you can remove the third party content or accept that you users are going to get warnings and either avoid your site, complain, or not care.
Imagine you are at amazon trying to check out with a credit card and you got this warning. How would you feel if amazon said, that is the responsiblity of the third parties?
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Erm..
And I can check where the form is submitting my data and make sure that that is secure at least.
But I think a more likely point is also a site with a forum with user generated content. Especially one allowing inline images. The forum should use SSL to protect user authentication information. But the users certainly aren't going to be only using https links in their image tags. So such a forum is guaranteed mixed-content warnings.
Of course that doesn't apply to Techdirt. No inline images here. The only problem is the advertisers. In this case, the advertisements are part of the Techdirt business model. They cannot be removed without also eliminating what I have been led to believe is an important revenue stream. So the ads have to stay.
Now, there are far more factors than just SSL in choosing who one uses as an advertiser. If the advertiser with the otherwise best deal doesn't offer SSL, then that puts you in a tight spot, doesn't it?
In any case, the info actually going to Techdirt still remains secure. So there are only two impacts here:
1. Someone with access to your line can see which advertisements you get. And that's gonna happen any time you visit a page using the same advertisement system. So nothing to really worry about, unless the advertiser is storing sensitive information in its tracking cookies.
2. Users who don't know what mixed content warnings indicate might get spooked by the "Caution" indicator in their browser.
Quite frankly, I find the second issue to be of greatest concern, and only for the folks running this site.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Erm..
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Erm..
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Erm..
You surely understand the massive grand canyon-sized difference between that example and people viewing an opinion blog, right?
[ link to this | view in chronology ]
Read
Hm, let's see... You're using a web browser developed by a for-profit, US-based multinational advertising/surveillance conglomerate/NSA "corporate partner" (i.e., collaborator) and PRISM-participant; your "local security" is mainly lacking in the existence area.
Read about NSA whistle-blower Ed Snowden's leaks, and read Bruce Schneier's blog if you're fool enough to trust Go-Ogle (or any other major US-based tech firms).
[ link to this | view in chronology ]
Re: Re: Erm..
Chrome's cert checking has a number of holes. Just because it doesn't flag a cert doesn't automatically mean the cert is OK.
[ link to this | view in chronology ]
Re: Re: Re: Erm..
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Response to: Anonymous Coward on Jul 24th, 2014 @ 8:05am
[ link to this | view in chronology ]
[ link to this | view in chronology ]
ODNI is what you would refer to as an 'anti role model'
[ link to this | view in chronology ]
Worse when i go look
http://tinypic.com/r/15ft9qx/8
Which says they (may be) trying to steal my information
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
https://www.techdirt.com/articles/20140717/03325427904/top-eu-politicians-call-taftattips-corpo rate-sovereignty-provisions-to-be-removed.shtml
[ link to this | view in chronology ]
This just proves he is right
[ link to this | view in chronology ]
It is not configured for https
[ link to this | view in chronology ]
[ link to this | view in chronology ]
If you put https in front of any site CNAME'd to Akamai that isn't paying for the extra SSL, you'll get basically the same error, because it sends you through their old edge network--it supports SSL, but it's for serving individual assets like images or swfs.
It's probably historically related to the way they rolled out different offerings. Basically, for this site, they didn't want to spend a few thousand extra a month for SSL offerings.
[ link to this | view in chronology ]
Re:
It may be that they are in the middle of a transition from direct hosting to using edge providers to give better service and to mitigate attacks on their servers. It's pretty normal. The SSL certificates will be all screwed up for a while, it's not a simple job to do when you are handling a network with so many possible exit URLs.
But hey, it's fun to slam them for trying to make things better, right?
[ link to this | view in chronology ]
Re: Re:
I found some other sites that will give you the same error:
https://www.pepsi.com
https://www.mountaindew.com
You can tell which sites are on the Akamai SSL network by seeing what they're CNAME'd to. If it's edgesuite.net, it'll give a cert error. If it's edgekey.net, it's good:
[agarvin@atg-home logs]$ dig +short www.pepsi.com
www.pepsi.com.edgesuite.net.
[agarvin@atg-home logs]$ dig +short www.aa.com
aa.com.edgekey.net.
Note this domain:
[agarvin@atg-home logs]$ dig +short www.dni.gov
www.dni.gov.edgesuite.net.
Look at the cert with openssl s_client and you'll see the CN is for a248.e.akamai.net.
[ link to this | view in chronology ]
Re: Re:
We don't mind that, what are the facts?
"It may be..."
Oh, you have none, you just wanted to inject a random theory that might allow you to white knight someone criticised in the article? Never mind.
[ link to this | view in chronology ]
Re: Re: Re:
Trying to pick a fight? You lose every time.
Fact: They are using akamai.
Fact: In a transition time, their existing certificate would not be accurate.
Fact: Their site is still secure, and in fact is likely more secure as a result of a move to use Akamai.
Your facts? name calling. Yup, you lost again.
[ link to this | view in chronology ]
Re: Re: Re: Re:
How so?
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
Not sure about Akamai itself, but similar services will also sink or stop attempts to connect ssh, ftp, mail, and the like, removing the burden entirely from your servers - at least for people who try to connect by name rather than IP.
http://www.akamai.com/html/solutions/security-services.html
Basically, the fewer people who interact directly with your server, the less chance of problems.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re:
As to stopping connections to ssh, etc., that's beyond trivial to do in the first place by just not running those servers. It takes more technical expertise to set up the servers than to not set them up, so the technically clueless are already safe on those fronts by default.
On your last point, that's true but the increased security you get that way is pretty minimal.
On the flip side, if you're relying on an edge provider to enhance your security, you're making a security trade-off. Those providers are well known, desirable attack vectors and draw the attention of far more, and far more skilled, crackers than your servers are likely to draw. And once they're hacked, all servers using them become vulnerable.
Edge providers are very useful for traffic management, but thinking that using them gives a security benefit beyond what you can easily do for yourself is dubious at best.
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
A man-in-the-middle attack? Against ODNI? By NSA?
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Java is affected too
Widespread MITM attack on security-sensitive sites? DNI, downloads for the (often buggy) Java plugin ...
[ link to this | view in chronology ]
SOP for the GOV
[ link to this | view in chronology ]
[ link to this | view in chronology ]
https://www.youtube.com/watch?v=pDmj_xe7EIQ
[ link to this | view in chronology ]