Slashdot Mirror

This works. It can be tested at Qualsys SSL Labs

If browsers complained about SSL errors, questionable, dated ciphers and odd configurations, a lot of pages would be considered "insecure".

Want proof? Take your favorite webpage and get a report from SSLlabs about it. And if you want more, throw the page against Securityheaders, too.

If you don't mind losing some sleep, try it with your favorite online banking page.

Agreed. Those of you that do have strict PCI compliance pushing this I can totally get behind. However, this is yet another think-before-acting approach and anyone who's married to any sort of Debian distro love. The pace of catch-up is just going to cause compatibility issues and if you think hand-rolling-and-replacing your openSSL integration on your distro with source is fun to get 1.0/1.1 support back? Think again. I'd rather be stung by 10,000 bees with a bucket of ice cream and a dozen roses in my lap.

I do disagree that havingTLS 1.0/1.1 enabled makes audit failure; it's still widely adopted and if you're not getting paid audits, pen testing or security scanning from a 3rd party giving you a paid and overly cautious analysis to be paranoid-secure, then it's 80-90% good for the rest of the world with public facing. I've always used SSL Labs as at least a 'me' benchmark for anything I do SSL anything and I don't see 1.0/1.1 as a blackmark on that, so it's hard for me outside someone, some entity or some policy driving it at my work or project, that it's still viable. Because it beats not having anything at all or using any SSLv2/3 crap.

There's a lot of good guides to proper end to end security, and plenty of systems that will check it for you.
https://www.ssllabs.com/

You won't get an A+ rating using your own personal CA, but it can expose a whole lot of other problems beyond simply the choice of certificate, and quite frankly if you follow any idiots guide to OpenSSL on the internet these days you'll generate a pretty secure certificate.

Their webmail server SSL config is rated F:

https://www.ssllabs.com/ssltes...

It supports SSL2! SSL2 was replaced by SSL3 a loooong time ago.

Oddly enough, SSL3 is disabled on this server (which is good, since it has many flaws, but not as many as SSL2).

And the ciphers it supports? It will use DES. That's single DES, not triple DES. 3DES replaced DES as a standard since 1999.

Not to mention 40-bit RC4, RC2, and other insecure algorithms.

Microsoft released an update to support AES on win2003 waaay back in 2008: https://support.microsoft.com/...
https://support.microsoft.com/...

Of course, it isn't installed.

Is this browser keybridged to Opera Corporate? Is Opera able to decrypt TLS sessions run through the VPN? Does this add Opera-controlled root CAs that allow mitm?

Opera Mini has terrible security, as it uses the native Android WebKit/WebView. Does Opera guarantee that anything it provides for this VPN has current patches and passes all relevant tests (i.e. http://ssllabs.com?

I loaded Opera Mini on a Jellybean device, and tested it against the best-known SSL/TLS Scanner.

Initial tests passed with flying colors, and indicated that I was using the "Presto" rendering engine, which routes traffic through Opera's server farm for compression.

However, after I reduced the "data savings" parameter in settings from "extreme" to "high," Opera Mini then FAILS with flying colors, because it's using the Jellybean Webkit directly (that lacks TLS1.2, bundles bad ciphers, etc.).

This is deceptive. Don't install this product.

Congratulations to the new team, thats a big step towards keeping their loyal audience regaining goodwill among the tech crowd.

The quality of the improvements and the effort of the new team is visible, it even gets an A on ssl quality test.

Good job and don't rest on the laurels, get working on the Unicode support because that's one of the missing features.

The Qualys SSL labs site is pretty useful: https://www.ssllabs.com/

1.No more stories that link to pay-walled sites or sites that wont load if you run an ad-blocker. This includes stores that link to Forbes and also stories where the primary source of the information is a journal article that costs money to read.

2.Get rid of (or at least make it possible to totally hide) the "slashdot top deals", "video bytes" and "get the slashdot newsletters" boxes.

3.Have a box in the firehose for "mark this as SPAM" where people can mark things that are clearly SPAM rather than a legitimate firehose entry so it can be removed or hidden (and we have less SPAM cluttering up the firehose)

4.Focus more on stories that are actually "news for nerds". The Tesla story a few stories above this one isn't "news for nerds" just because its about Tesla. The story about the democrats in Iowa isn't "news for nerds" either. Nor are stories about labor issues at Uber or the fact that some company (technical or otherwise) is firing a bunch of people.

5.Get rid of all bundled downloads and adware and stuff on Sourceforge. Every file Sourceforge sends out should be the exact file uploaded by the projects owners.

6.https support with all the latest security stuff. If it doesn't get the highest possible mark on https://www.ssllabs.com/ssltes... you are doing it wrong IMO. This includes doing everything possible to prevent man-in-the-middle attacks. (I believe at least one of the Snowden leaks pointed to Slashdot by name)

7.Make the site more lightweight (anything that can be done to reduce the size of page downloads is a good thing)

8.Completely end the use of Flash or any other closed-source plugin anywhere on Slashdot. Yes that includes getting your ad provides and those who advertise on the site not to use Flash (or getting new ones if they wont agree).

9.Do everything possible to prevent the site (including the ads on the site) from serving up any kind of malware. (ending the use of Flash and Flash ads will help with this since Flash is the #1 malware delivery system on the web)

10.Editors who do their job. No more stories missing a link to the actual article or with spelling mistakes everywhere.

I think it is very vulnerable given that it gives me a cert error due to a misconfiguration and https://www.ssllabs.com/ssltes... shows how terribly insecure its ssl setup is. If they haven't updated that, they probably fell behind the other updates as well. But all that doesn't matter as 2003 is out of both support windows, IIRC.

Oh its worse than that... Poodle anyone

https://www.ssllabs.com/ssltes...

Oddly, Google still uses RC4, according to Qualys test. They also still allow SSLv3 and have not yet moved to SHA2 signed certificates.

Try tponline.co.uk - which is the UK , Teacher's Pension (and List 99 temporary criminal record check before the "proper" check is done) website.

Ironically, it's one of the few website that REQUIRES a client certificate for every user who logs into it (which is a pain in the butt and costs a fortune as only they can supply the correctly signed client certs).

The signup page, however? SSL v2.0 and vulnerable to EVERYTHING:

https://www.ssllabs.com/ssltes...

An "F" rating on SSL Labs. First time I've ever seen that on a domain that I've thought to check.

I have to admit that I didn't test MSIE, due to a fundamental lack of Windows on my home network.

SSL Labs has a website will test HSTS on various IE versions for you: https://www.ssllabs.com/ssltes...

Firefox has already done this. Since Firefox 37 the default preference does not allow fall back to TLS 1.0 or 1.1. So if your bank's website is not using TLS 1.2 then you will not be able to connect to it. There is no user friendly UI to change the setting, but you can change the fall back setting using the about:config mechanism. Check the release notes here - https://www.mozilla.org/en-US/... Also SSL labs has already planned to give low grade to websites using RC4 over next few months - https://community.qualys.com/b... You can check the status of your baks security infrastructure with ssl labs scanning tool and complain about it in bank support forum - https://www.ssllabs.com/ssltes... The client I worked for has same problem with some websites and hence started getting calls from customers. Thankfully they have quickly recognised the potential loss of business and are working on upgrading the infrastructure.

In addtion to sending the CSR, and not the key, scan your SSL server with the SSL Labs Scanner and you will see many flaws.

To fix these flaws, apply these cipher best practices to lock out bad ciphers (RC4, export-grade ciphers), and deny the entire SSLv3 protocol which now has critical design flaws.

The key to the best-practice ciphers are these Apache directives (this configuration is also effective on the older 0.9.8 OpenSSL):

SSLProtocol ALL -SSLv2 -SSLv3
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
SSLCompression Off
SSLHonorCipherOrder On

To summarize:

• - Apply vendor patches for your OpenSSL with some degree of haste.
• - Check the best practice cipher page at least once per quarter.

The Social Security website gets and "F", too. And it has been that way for quite some time.
https://www.ssllabs.com/ssltes...
So damned if you do, damned if you don't.

Funny, I looked at the link too, and saw an F.

But most worrisome was the bottom of the page, showing:

Microsoft-IIS/7.5

It's bad enough to use web based mail, but to run it on IIS?

I followed your link, it says B.

Funny, I looked at the link too, and saw an F.

But most worrisome was the bottom of the page, showing:

Microsoft-IIS/7.5

It's bad enough to use web based mail, but to run it on IIS?

https://www.ssllabs.com/ssltes... produced a big red-boxed 'F' when I clicked on it. Perhaps their server isn't doing well with the load of Slashdot's attention?

Sigh.

So, as I understand it, the current situation is:

- We can't allow use of RC4 because it's weakened significantly.
- If we disallow RC4, we open ourselves up to BEAST in practical terms.
- We need to move towards PFS and TLS 1.2 but the major libraries don't support it in major stable versions and/or we break an awful lot of the world's clients in doing so.
- A lot of the chain certificates out there are still using only SHA1 which makes them weak.
- And now we have to start worrying about clients that allow downgrade attacks on the connection.
- We can't use OpenSSL at the moment because all the interesting new features (TLS 1.2, etc.) are only in Beta.
- We can't use LibreSSL at the moment because it isn't available in many mainstream distros.

Seems to me like we really need a massive revamp of security here and ditching old clients entirely.

Almost every site on the Qualsys Labs tests rates B at best now because of the current situation (from which they recognise there is no practical escape even though it should probably rank them all lower): https://www.ssllabs.com/ssltes...

I think it's time we just ditched everything and provide a way for browser security to be pulled out of the browsers entirely and made independently upgradeable, so you can browse a modern TLS 1.2 site with a browser that's a few weeks old.

Yes. http://www.openssl.org/docs/apps/ciphers.html

The question is does OpenSSL accept the weak ciphers as a downgrade bug even when EXPLICITLY DISALLOWD.

I haven't seen answered in any of the linked articles so am digging/testing.

After the last couple of bugs my organization set the explicit cipher/algorithm/has acceptable list. The export ciphers were excluded on purpose from our list.

SSL Labs https://www.ssllabs.com/ has a recommended list buried in their documentation somewhere.

Why start with something bad to make something good. If you want a good SSL library, try PolarSSL. It's a quite unknown, but great library. Unlike OpenSSL, this one has good documentation. The Hiawatha webserver uses it and it easily gives me an A+ score at SSL labs.

The article references the SSL Labs tool which includes the TLS POODLE test: https://www.ssllabs.com/ssltes...

https://www.ssllabs.com/ssltes...

IE 11 / Win 8.1 R TLS 1.2 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) No FS 256
Chrome 37 / OS X R TLS 1.2 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) No FS 256
Firefox 32 / OS X R TLS 1.2 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) No FS 256

Other than the lack of Forward-Secrecy and lack of GCM it looks like Citi supports modern TLS.

Yeah, you're a fucking moron. Wish I had some way to make you actually pay up: not only do they only support TLS (and have downgrade protection for good measure), they default to perfect forward secrecy with all clients. https://www.ssllabs.com/ssltes...

I suppose you think Slashdot is more secure? This site you're posting on, which doesn't even *allow* people to browse using HTTPS (it redirects you back to HTTP immediately), doesn't do PFS by default, still uses SSLv3 without downgrade prevention (it "mitigates" POODLE by using the known-weak RC4 cipher instead)? If you think Slashcode is so "inherently broken", why are you using this site?

I sincerely doubt you understand anything at all about why SSLv3 is problematic. Mandating TLS 1.2 exclusively would also be rather poor policy for most public sites; TLS 1.1 should almost certainly be considered an acceptable protocol for general use. It's telling that you didn't bother to comment on ciphers and signature algorithms, forward secrecy, and related concerns. Perhaps this may be explained by your having just started your studies on these topics this past weekend.

People lacking a solid foundation in information security would be well advised refrain from the sort of commentary you've offered here, lest they risk appearing foolish themselves. Incidentally, soylentnews.org does not support SSLv3, and it does support TLS_FALLBACK_SCSV. As you're clearly lacking the ability to make such determinations for yourself using something like s_client or similar, you may wish to utilize resources such as the Qualys Server Test before making haphazard guesses in the future.

I have no association with soylentnews.org or Qualys, but I thought others might benefit from an educated reply to your brave assertions. Cheers!

(philip.paradis posting AC here, as I do not log in on this computer)

I have a million other things to deal with.
I'll just run my shit against https://www.ssllabs.com/ssltes... in a month and do what it tells me to.

Except that is out-of-date information so it is meaningless to this discussion: https://www.ssllabs.com/ssltes...

I was just using https://www.ssllabs.com/ to check out some financial sites:

amhfcu.org : F, supports insecure SSL 2.0
tdbank.com - A-

republictt.com/ - not the local bank.. apparently uses java.. .ugh..
republicbank.com - powered/provided by intuit - A-

sjfcu.online-cu.com - B - due to not supporting TLS 1.2. (used by likely a few cu)

bankofamerica.com - inconsistent - B, A-
wellsfargo.com - B - due to not supporting TLS 1.2
paypal.com - A- uses mixed content on home page.. really?

secure.ally.com - B - TLS 1.2 capped
https://www.chase.com/ - A-

hsbc.com -asks for login name on insecure website.. otherwise a B

I'm not impressed. My ~$10 a month Dreamhost account can get me a B rating (with SSL kindly provided by https://www.startssl.com/ for free). And if they were running a newer version of Debian, I think it would be an A.

Major security fail Slashdot. You've let your SSL server certificates expire. https://www.ssllabs.com/ssltest/analyze.html?d=www.slashdot.org&s=216.34.181.45

"The security flaw in the Chrome browser emerges just as the world is confronting the frightening prospect of an undetectable bug known as Heartbleed, that makes millions of passwords vulnerable to being stolen".

'It is being widely reported in the popular press as well as many technical sites that a Heartbleed exploitation "leaves behind no trace"`. That of course is not true.

SSL Server Test

There have been a number of sites.
SSLLabs scanner has been updated to check for Heartbleed, and also will report when the cert validity starts (handy if you want to see whether they're using a new cert). https://www.ssllabs.com/ssltes...
LastPass has a pretty decent scanner that just focuses on Heartbleed (without all the other info that you get from SSLLabs): https://lastpass.com/heartblee...
There are some others out there as well, of course.

There's even one for client-side testing (almost as critical):
Pacemaker is an awesome little POC script (python 2.x) for testing whether a *client* is vulnerable (many that use OpenSSL are...). https://github.com/Lekensteyn/...

Qualys SSL Test is including a flag for Heartbleed vulnerability and auto-fails any domain tested that is affected.

The places the NSA would need cooperation are the commonly-utilised SSL-accessed services, primarily Facebook and Google mail/docs. Can't just fiber-tap those, and even if you could it'd be a nightmare trying to reconstruct things from taps alone. Having access to their databases would make utilising the information a lot easier.

Google has implemented Perfect Forward Secrecy (via ECDHE) since 2011 for clients which support it. You can test sites yourself with the Qualsys tool, look for 'FS' in the cipher list.

The widespread use of PFS will mitigate a purely human vulnerability: a distinct possibility that a some few humans in each of these major providers could be secretly supplying NSA with the operational SSL private keys that are used for HTTPS/SMTPTLS/SPOP/SIMAP.

Without PFS, imagine someone working IT at a bank exchanging a tiny flash drive containing years' worth of private SSL keys for a briefcase full of money. The moment the spooks plug in those keys, years of recorded encrypted SSL intercepts become readable, instantly. We are still at this stage, and most of the Internet is still vulnerable to this approach.

Is NSA/Utah breaking encryption codes with servers in a facility that requires 1.7 million gallons of coolant water per day? To some extent maybe, but the main emphasis will be on mass collection and bulk storage. And I am sure they have a map of tap points that surround Tier One exchanges, with an ever-increasing number of pins placed on it. Stalin would be proud.

Going into telephones -- cell providers aggregate roaming and billing information in a few central COs where a stream of call data is received. Land line providers are no different, and since there are no landline-only telecom providers left, the call information is likely to be accumulated in a few central places. Just a few taps and they have all the call and roam data they are accustomed to receiving. Will those telecom providers become aggravated that NSA is tapping their central offices, as Google is? Nope, with a nudge nudge wink wink they will leave their call metadata links encryption-free and be grateful that the straw man of voluntary data sharing has been brought down.

The ONLY HOPE of thwarting this turnkey police state is to publicly expose the existence of the taps (thank you Snowden) and DEFUND and DISMANTLE them.

There are two ciphers family that will provide PFS: DHE (Diffie-Hellman Exchage) and ECDHE (Elliptic Curve DHE). Having PFS enabled for all modern browsers is just about the server offering both families with appropriate priorities, so that clients pick a PFS enabled cipher. Qualys SSL server test is a good tool for checking for an appropriate configuration, although it could make clearer that you cannot both have PFS for modern browsers, and protect against BEAST server-side.

Note that the Elliptic Curve used in ECDHE is not the one that was claimed to be compromised by NSA. We have no information suggesting ECHDE is at risk

Qualys published a list in August of this year for Java 6 Update 45 that lists the default Cipher Suites in order of preference. On that list there are 4 that are insecure but there 7 that are weak. What needs to start happening to fix this is
1) App vendors need to become aware of the situation.
2) Disable use of the weak and vulnerable ciphers. This can be done on the web server for example as a start.

Remember it takes two to tango in an SSL/TLS handshake and if one side says No to a weak or vulnerable Cipher then one of the stronger Ciphers (if available) can be used. If you're using weak or vulnerable ciphers at all, fix your app. We also have to push to get rid of any of the older than TLS 1.1 and keep pushing on the Browsers to support TLS 1.2 which oddly enough only MSFT has supported since IE8 and Opera since version 10. http://en.wikipedia.org/wiki/Transport_Layer_Security

If I understand correctly, it is a system wherein a unique public/private key pair is generated on demand using a long term key. Or to put it more simply -- a system that gives every session a new and unique set of encryption keys, thus making compromise of the private key hugely less of a bonanza. If that's the case, that sounds like a great system.

Why do you need a public/private key pair?

Just use Diffie-Hellman key-exchange over the SSL public/private channel to create a symmetric key and use the symmetric key for actual data transfer.

In any case, I don't know what the GP is talking about: DuckDuckGo has forward secrecy, it does use RC4 though which isn't a very good cipher.

SSL offering at Ixquick and Startpage are way better. DuckDuckGo doesn't even support TLS 1.1 and 1.2 yet.

SSL offering at Ixquick and Startpage are way better. DuckDuckGo doesn't even support TLS 1.1 and 1.2 yet.

Ixquick and Startpage offer better SSL than DuckDuckGo. They have TLS 1.1 and 1.2 (DDG has only 1.0), and have enabled TLS 1.2 256-bit ciphers with a higher priority. I think they still keep RC4 for TLS 1.0 and SSL 3.0 to mitigate the BEAST attack for CBC ciphers, since 128-bit RC4 is the better devil until everybody moves to TLS 1.2.

Ixquick/Startpage seem to have servers in both the US and Europe.

https://www.ssllabs.com/ssltest/analyze.html?d=startpage.com&s=69.28.209.119

https://www.ssllabs.com/ssltest/analyze.html?d=ixquick.com&s=69.90.210.8

Ixquick and Startpage offer better SSL than DuckDuckGo. They have TLS 1.1 and 1.2 (DDG has only 1.0), and have enabled TLS 1.2 256-bit ciphers with a higher priority. I think they still keep RC4 for TLS 1.0 and SSL 3.0 to mitigate the BEAST attack for CBC ciphers, since 128-bit RC4 is the better devil until everybody moves to TLS 1.2.

Ixquick/Startpage seem to have servers in both the US and Europe.

https://www.ssllabs.com/ssltest/analyze.html?d=startpage.com&s=69.28.209.119

https://www.ssllabs.com/ssltest/analyze.html?d=ixquick.com&s=69.90.210.8

Use this it details towards the bottom the ordering of ciphers.

Hi, this is Gabriel Weinberg, CEO and founder of DuckDuckGo. I do not believe we can be compelled to store or siphon off user data to the NSA or anyone else. All the existing US laws are about turning over existing business records and not about compelling you change your business practices. In our case such an order would further force us to lie to consumers, which would put us in trouble with the FTC and irreparably hurt our business. We have not received any request like this, and do not expect to. We have spoken with many lawyers particularly skilled and experienced in this part of US and international law. If we were to receive such a request we believe as do these others it would be highly unconstitutional on many independent grounds, and there is plenty of legal precedent there. With CALEA in particular, search engines are exempt. There are many additional legal and technical inaccuracies in this article and I will not address all of them in this comment. All our front-end servers are hosted on Amazon not Verizon, for example. A couple other responses to things I've noticed in the comments already: --Our servers are already located around the world. European users are generally not hitting US-based servers, for example. --We do have PFS on our cert: https://www.ssllabs.com/ssltest/analyze.html?d=duckduckgo.com&s=50.18.192.251

One can find the answer in seconds.

Slashdot has no class, and it's readers are incapable of browsing deeper than one link click. That's why there are so many frustratingly dumb questions here.

Here, have a bowtie.

plus SSL encryption being picked apart

Only if system administrators fail at configuration.

If that is the whole problem, why not rename the https protocol to "secure"?

I personally don't think it's a bad idea to make secure:// an alias of https://./ The only problem would be that just using https does not tell anything about the connections actual security.

So I tried my SNI enabled domain, which redirects to a dummy domain if you don't support SNI.

And https://www.ssllabs.com/ssltest doesn't work with the SNI domain, thinking my certificate is invalid.

So a few things:

* It's sponsored by Qualis, I don't see how that's trustworthy. You see that only once you do the actual validation. They're here to make money like any other corporation. Nonprofit stuff? Bitch please.
* It doesn't work with SNI so there's million domains wrongly counted as invalid
* Their cert isn't even an EV cert