[anon(2729369)]

They only need to upgrade to TLS 1.2 if there is something provided by that protocol that is necessary. Closing the door to the known problems with TLS 1.0 does not require upgrading to TLS 1.2, nor is upgrading to TLS 1.2 sufficient since if you communicate with a peer that only supports TLS 1.0 and you haven't fixed the problems then you are subject to the vulnerability anyway.

I completely disagree with you. TLS1.2 is needed to be able to use better cipher suites. You can't backport that.
And it's not about protecting UK banks which insist on using suites or a protocol version on the verge of being broken, but about offering the possibility to businesses and service providers to use what TLS 1.2 has to offer.

And btw, this is from BlackBerry's dev doc:
"We strongly recommend that MD5 or SHA-1 not be used. You should plan to migrate to SHA-2 algorithms (or stronger) where possible. NIST recommends that SHA-1 should not be used for hashing after the end of 2010 for government applications"

Heartbleed on the other hand is an example of why one should not rush to adopt new features unless they are needed. I wonder how many systems that are vulnerable to heartbleed actually need the heartbeat extension. One of the reasons my users and I don't have to be concerned about the systems I manage is that for the past two years we have been using OpenSSL 0.9.8 of various sub-versions that track the bug fixes of 1.0.1 but lack the addition features we don't need, like heatbeat.

The heartbeat extension has been implemented over 2 years ago to support DTLS which is very useful for VoIP apps. It's not some untested, beta feature which was bundled with the library, waiting to be exploited. It's just very unfortunate that the boundary was left unchecked.
It's true that most servers probably didn't need it, but then it's a problem with package management on Linux. On a mobile OS though, you want to offer as many features as you can so that app developers can build the apps people want.
And congrats on making the Internet less safe (except this week) by making sure you don't offer strong encryption on your servers ...The main reason some distros are still offering 0.9.8 is that they have long support cycles and don't update core libraries because it can break things, but it's usually still possible to manually upgrade.

BlackBerry is not perfect. It will be interesting to see, as time moves on, what the specifics behind the vulnerable products are. But if it comes down to believing that BlackBerry needs to do something because you say they do, or looking at BlackBerry's track record and concluding that they in fact know what they are doing, I'm going to have to side with BlackBerry on this one. There are choices in the market. If having TLS 1.2 on their smartphone is important enough to someone, they can exercise their freedom of choice. At the end of the day BB10 is not vulnerable to any of the things you sought to raise awareness of. People should not loose sight of that.

Yes, I'm curious to see how one can attack BBM or Workspace and what can really be extracted from that. Regarding BlackBerry's track record, well, as shown in my quote from their dev site above, they're contradicting themselves sometimes, by saying: don't use that, like we do.
At the end of the day, BlackBerry 10 and your servers don't seem to be vulnerable to Heartbleed, but are not offering the best protection for data in transit. People should not lose sight of that.

[Richard Buckley]

... your servers don't seem to be vulnerable to Heartbleed, but are not offering the best protection for data in transit. People should not loose sight of that.

Well thank you for your opinion. But I have not leaked server keys, email, passwords, or anything else in the past two years. Its a matter of perspective. In this case the difference between being sure you have good security, and being right vs thinking you have better security and having none.

[anon(2729369)]

Well thank you for your opinion. But I have not leaked server keys, email, passwords, or anything else in the past two years. Its a matter of perspective. In this case the difference between being sure you have good security, and being right vs thinking you have better security and having none.

That you know of .
BlackBerry also thought that their infrastructure was safe and yet, some of their secure certificates may have been stolen.
Many companies find out that their online clients DB has leaked once customers start letting them know.
Merkel thought she had some privacy when making phone calls.
Etc.
There is always a weak link somewhere and the right balance to be found between stability and features. Some businesses require to be conservative, others to be innovative. What matters is that your clients are happy with the service your offer and I'm sure it put a smile on your face to be able to tell them all that you were not vulnerable .

[Richard Buckley]

That you know of .
BlackBerry also thought that their infrastructure was safe and yet, some of their secure certificates may have been stolen.
Many companies find out that their online clients DB has leaked once customers start letting them know.
Merkel thought she had some privacy when making phone calls.
Etc.
There is always a weak link somewhere and the right balance to be found between stability and features. Some businesses require to be conservative, others to be innovative. What matters is that your clients are happy with the service your offer and I'm sure it put a smile on your face to be able to tell them all that you were not vulnerable .

All true, but you make it sound like I lucked out. I've been dancing with OpenSSL essentially since it came out. It is not what anyone would call an impressive or clean corpus of code. I've been dancing with BB code since BBOS 4.1, attended a Tablet OS security briefing ahead of the PlayBook release, attended a postmortem of the BBOS6 browser CANSECWEST pown to own results and have been able to talk to the most knowedgable QNX OS people on earth about the BlackBerry take over and preparation for BB10. That experience alone is easily enough to convince me of who I needed to keep an eye on (OpenSSL) and who I could trust to have my back (BlackBerry).

I don't believe it is a coincidence that the BlackBerry products that are vulnerable run on someone else's systems. I've test my iOS 7.1 devices, which are clean, and my MS Win systems, also clean. But apparently Jelly Bean has the bug, so that probably explains BBM on Android.

The programmer who wrote the code to implement heartbeat has explained how he came to create this bug. He wrote the code and neglected to check the field length field for a reasonable value. Another programmer check the code, and that's it. This is a very error prone way to code, and it is not surprising that a problem occured. It was enevitable, if not him, someone else would have made a mistake somewhere else that didn't get found before production code shipped. As I said the code base has never been great, and was not really improving. That is one of the reasons I stuck with 0.9. That and the distribution I personally run decided to stay there as well. And it is not just because of long update cycles, many other layered products have kept closer to the leading edge. If you compare that coding style with the way BlackBerry internals are coded it is like night and day. BlackBerry OS programers wouldn't even consider using a value provided by the other system and then hope to detect bad ones. They would code it so they would get that value from a trusted source on the local system. Even I though that two years was enough and was in the process of standing up a system that would support TLS 1.2 and it has been on the net for a couple of weeks. Luckily with no client data on it. But I also know that there is no significant qualitative difference in the cryptography available to TLS 1.0 and TLS 1.2. In fact both systems receive the same score from SSLLabs.

Newer, bigger, faster is not always better. This is even more true for mission critical or security related software. There was one month between the time the heartbeat RFC was finalize to when OpenSSL 1.0.1 was released. That is not long enough. The bug persisted for two years available to anyone who cared to look at it, and through six update releases. About the same specs as the goto fail bug. It is starting to look like hanging back two years from the development head isn't going to be long enough. It is a good thing that cryptographers plan 10 or more years in advance.

I was thinking of trying to write something that would produce something you would accept as proof that BB10 is safe. The truth is, even though my phones and systems aren't affected, there important infrastructure that is way to badly broken to wast time checking systems that trustworthy companies have said are clean. That and the fact that the certificate revokation system has grass growing through it and may not work. And this may not be the last we've heard from OpenSSL vulnerabilities. It is shaping up to be a very busy summer.

[anon(2729369)]

Very insightful, thank you
I do think there is an element of luck. Some Linux kernel or OpenSSH vulnerabilities took years to patch and the NSA has a treasure trove of exploits they can use. Some of which, I'm sure, leave no trace.
Of course, your approach makes it so that it's much harder to penetrate your network, but you could have suffered as well if that bug had only been discovered a couple of years from now, since you had already started to use the new version in production. There are so many moving parts that, unless you have very deep pockets and check the source code of everything you use, you're bound to be affected one day by a serious vulnerability. The next one could be the collapse of TLS 1.0 which would force many service providers to rush the upgrade, although I'm sure you have test envs which are already running everything you need, just in case .

OpenSSL's code is messy and the foundation lacks the funding to perform regular audits, but so much software depends on it that it's difficult to avoid. That's probably what happened with BBM on iOS and Android, but let's see if BlackBerry elaborates on that, before I make any more speculations .
Also, BBM on BlackBerry was affected since part of the backend was vulnerable. Let's wait for BlackBerry's full analysis to see what the potential risks were.

Newer, bigger, faster is not always better, but if you want to use TLS 1.2 which is qualitatively different from TLS 1.0 from my pov (GCM, poly1305, etc.), you need to upgrade. If I'm not mistaken, you can't get an A+ on SSLlabs if you're only using TLS 1.0. And yes, x.509 is broken, but we're probably still a decade away from a solution.

I don't think that bug was there because it was written too soon after the RFC. It's a stupid bug with large consequences. I do think OpenSSL's release process is broken though. Any feature you turn on by default should be audited. The code should have been revisited before releasing 1.0.1e.

BlackBerry should scan every app in BlackBerry World if they allow library bundling in apps. The large Android community quickly came up with a list of affected OS builds and apps. This is completely missing on the BlackBerry side, apart from that short statement in the KB.

And finally, Iagree that we're not done and I hope large companies with vulnerable software and networking equipment will start properly funding OpenSSL.

[Superdupont 2_0]

Well,
at first I would like to thank the OP and other participants for this fascinating discussion.

Please allow me to add a short comment that is clearly Semi-OT:
1. The browser of my Playbook (OS 2.1.0.1917) is vulnerable to BEAST.
2. The browser of my Curve 9320 (OS 7.1.0.1033) is using insecure cipher suites

While I am confident that BlackBerry will fix the browser security of OS 7.1 and OS 10.2, I am really alarmed about the Playbook browser.
I enjoy using MS ActiveSync (Hosted Exchange) and chose BlackBerry for security, because my mobile devices are often “exposed” in public Wi-fis (hotels, airports, cafes…).

Especially during my stays in hotels etc etc... I have to trust in the SSL/TLS protocols of (the Hosted Exchange and) my mobile devices also for appworld, videochats, e-mail, calendar and contacts. If the browser security of the Playbook is already clearly behind, it should not take too long for the rest…and I really like my Playbook.

While I understand that this thread should focus on the Browser of BB10, I really hope that BlackBerry will respond to this problem “globally” (= looking for similar deficiencies in all other products/services), including the loyal fanbase still using the Playbook (and not tablets from the competition).

As already mentioned elsewhere in this thread, the certifications hold by BlackBerry probably slow down the process, I assume every little action in this sensitive field will be subject to Change Control, Validation Procedures and final approval from their, uhmm, “key accounts” (Three Letter Agencies).

Well, thanks again for making me aware that TLS is not as trivial as I thought.

[anon(2729369)]

Thanks for adding interesting facts to the conversation . Let us know when they patch OS 7.1. BlackBerry OS is their most popular OS, so they're probably taking things seriously.

Regarding the PlayBook and Wifi, you should always use a VPN when connecting to insecure hotspots. BlackBerry makes it difficult for us by only allowing a restricted set of VPN technologies, but there are providers out there who support BlackBerry devices.

[Richard Buckley]

Well,
at first I would like to thank the OP and other participants for this fascinating discussion.

Please allow me to add a short comment that is clearly Semi-OT:
1. The browser of my Playbook (OS 2.1.0.1917) is vulnerable to BEAST.
2. The browser of my Curve 9320 (OS 7.1.0.1033) is using insecure cipher suites

While I am confident that BlackBerry will fix the browser security of OS 7.1 and OS 10.2, I am really alarmed about the Playbook browser.
I enjoy using MS ActiveSync (Hosted Exchange) and chose BlackBerry for security, because my mobile devices are often “exposed” in public Wi-fis (hotels, airports, cafes…).

Especially during my stays in hotels etc etc... I have to trust in the SSL/TLS protocols of (the Hosted Exchange and) my mobile devices also for appworld, videochats, e-mail, calendar and contacts. If the browser security of the Playbook is already clearly behind, it should not take too long for the rest…and I really like my Playbook.

While I understand that this thread should focus on the Browser of BB10, I really hope that BlackBerry will respond to this problem “globally” (= looking for similar deficiencies in all other products/services), including the loyal fanbase still using the Playbook (and not tablets from the competition).

As already mentioned elsewhere in this thread, the certifications hold by BlackBerry probably slow down the process, I assume every little action in this sensitive field will be subject to Change Control, Validation Procedures and final approval from their, uhmm, “key accounts” (Three Letter Agencies).

Well, thanks again for making me aware that TLS is not as trivial as I thought.

It is unfortunate that you chose to go to the "howsmyssl.com" site, self described as

... a cute little website that tells you how secure your TLS client is.

If you read what they have to say about the BEAST vulnerability, how they determine vulnerability and their ability to detect mitigation; then read what Ivan Ristic has to say about BEAST, you will see that it is not quite as black and white as the cute site would have you believe.

In fact a much bigger problem that will be an issue for PlayBook owners for the next 18 to 36 months is the lack of OCSP Stapling. This will probably never be fixed because we've seen the last update to Tablet OS. The reason this is important is that the Heart Bleed bug could have allowed malicious actors who knew about it before sites were patched to get their hands on the private keys that go with fully signed certificates. The only way for a browser to tell if those certificates aren't good is by determining the revocation status of each one. OCSP Stapling makes that practical but it is not fully implemented accross the internet. Any malicious actor in a position to try a BEAST attack, and maybe succeed, is in the perfect position to just impersonate a website with a certificate they have stolen using Heart Bleed. Any browser or TLS application that doesn't check for certificate revokation, or that soft-fails when checking is vulnerable.

As far as your Curve is concerned, I don't know where in the world you are, or what market the device was first sold into, but the ciper suits I can almost make out in the picture seem to be EXPORT suits. Crypto technology export restrictions may seem moribund, but they are still in effect. Two systems can only communicate using TLS if they can find a cipher suite in common, much like two people who have to find a language in common. That is why clients and servers all have more than one suite specified. Clients need to have a suite that is valid for each server they may have to talk to. If they are unable to find a suite in common the TLS connection will fail. All international pilots and air traffic controllers have to learn a subset of english so they can communicate with each other. Their command of english may not be very good, but it is better that a pilot from one country can talk to air traffic control in rudimentary English than not at all.

[Omnitech]

Someone from 'The Register' actually reads our forums :|

Actually one of the principals there is a Crackberry user and quite the BlackBerry fan, and has written several laudatory articles about BB10.

We should be grateful that The Reg is one of the very few relatively high-profile tech news sites that actually has an honest-to-goodness BlackBerry fan on their staff.

The results from SSLLabs is proof.

We don't need to find that out. If you read my post with the reply from BBSIRT you know that they are looking into it and will take action if required. That would probably be responsible disclosure to vendors who are using it, if it is vulnerable.

What worries me more is that regardless how serious a vuln they discover and fix in a current OS build, who knows how many months it might take before all their customers can update to that version or later. This is a serious Achilles Heel with BB10.

Not only is the OS fragmented amongst all the various builds that various carriers around the world support, but even a completely trivial update (such as, for example, recompiling a binary without a certain feature enabled) would presumably require an entire core OS forklift upgrade to deploy, and carriers are notoriously slow to act on these things.

Whereas Apple can push a global patch to ALL their customers in a matter of days if they want.

And yes, I realize that Apple is more or less in a class by themselves in that respect. I don't know if it's easier for Android or WP to apply a simple patch compared to how it seems to be done on BB10. (Update the entire core OS and deal with all the inevitable glitches that crop up.)

[Omnitech]

And btw, this is from BlackBerry's dev doc:
"We strongly recommend that MD5 or SHA-1 not be used. You should plan to migrate to SHA-2 algorithms (or stronger) where possible. NIST recommends that SHA-1 should not be used for hashing after the end of 2010 for government applications" [...]

Regarding BlackBerry's track record, well, as shown in my quote from their dev site above, they're contradicting themselves sometimes, by saying: don't use that, like we do.

Left hand and right hand communicating with each other seems to be a perennial BlackBerry problem, I'm afraid.

It's true that most servers probably didn't need it, but then it's a problem with package management on Linux. On a mobile OS though, you want to offer as many features as you can so that app developers can build the apps people want.

That last part sounds conspicuously similiar to the traditional modus operandi of a particularly large software vendor based in Redmond, Washington USA.

Proof about the browser only. Different parts/apps of the OS use different libraries. The libssl they ship is: "OpenSSL 1.0.1e 11 Feb 2013", which comes with TLS 1.2 support. Apparently, just like on Android, heartbeat wasn't turned on, so we have nothing to worry about, as far as the OS is concerned.

And it is certain "coincidental" things like that that often make me wonder whether BlackBerry in some cases knows a lot more about what is going-on than they may be willing to let on. Perhaps with a little help from friends in high places.

[anon(2729369)]

And yes, I realize that Apple is more or less in a class by themselves in that respect. I don't know if it's easier for Android or WP to apply a simple patch compared to how it seems to be done on BB10. (Update the entire core OS and deal with all the inevitable glitches that crop up.)

A website has recently published their analysis of how long it takes Android manufacturers to push updates and you're only safe with a Motorola or Google device. Samsung and HTC are slow and forget about the rest, although they didn't test some of the smaller Chinese manufacturers like Oppo.

[Omnitech]

OpenSSL's code is messy and the foundation lacks the funding to perform regular audits, but so much software depends on it that it's difficult to avoid.

Theo de Raadt has stated that the OpenSSL people are irresponsible, and this is why he has put together a team now to fork it.

As much as de Raadt is oftentimes a bit of a crank, in this case my gut says that he's probably right.

If you read what they have to say about the BEAST vulnerability, how they determine vulnerability and their ability to detect mitigation; then read what Ivan Ristic has to say about BEAST, you will see that it is not quite as black and white as the cute site would have you believe.

I personally enjoyed how a browser could get a "needs improvement" rating because it doesn't support Session Tickets, but not a peep about the fact that some other, "probably good" browser offers a cipher suite that uses MD5.

And the fact that for the longest time, most of the "Heartbleed testers" out there were simply looking for OpenSSL versions and cert timestamps, when in fact as we all know now that it isn't so much the version but the heartbeat extension (and duh, you could have actually done a handshake to test this), and certs can be re-issued without changing the timestamps too.

In fact a much bigger problem that will be an issue for PlayBook owners for the next 18 to 36 months is the lack of OCSP Stapling. This will probably never be fixed because we've seen the last update to Tablet OS. The reason this is important is that the Heart Bleed bug could have allowed malicious actors who knew about it before sites were patched to get their hands on the private keys that go with fully signed certificates. The only way for a browser to tell if those certificates aren't good is by determining the revocation status of each one. OCSP Stapling makes that practical but it is not fully implemented accross the internet. Any malicious actor in a position to try a BEAST attack, and maybe succeed, is in the perfect position to just impersonate a website with a certificate they have stolen using Heart Bleed. Any browser or TLS application that doesn't check for certificate revokation, or that soft-fails when checking is vulnerable.

When I found out how MOST web browsers basically don't fail a revoked certificate AT ALL or throw up any warning at all, it blew my mind.

If I'm not mistaken, this is STILL true. (Opera is a rare exception. At least version 12. For all I know they went along with the rest of the sheep with their new Google Frankenbrowser.)

Also - apparently both Firefox and IE (and possibly others like Safari) do not do proper checking for Perfect Forward Secrecy, and give that nice "green glow" in the URL bar whenever they see an EV cert, despite the fact that it may not actually be warranted without PFS.

[Richard Buckley]

What worries me more is that regardless how serious a vuln they discover and fix in a current OS build, who knows how many months it might take before all their customers can update to that version or later. This is a serious Achilles Heel with BB10.

Not only is the OS fragmented amongst all the various builds that various carriers around the world support, but even a completely trivial update (such as, for example, recompiling a binary without a certain feature enabled) would presumably require an entire core OS forklift upgrade to deploy, and carriers are notoriously slow to act on these things.

I would not be concerned with WP but with Android there are often issues beyond carrier delays. Manufacturers quite often don't provide upgrades for all of their phones. BlackBerry at least has always provided updates as long as the hardware can handle them.

Also if you examine the BlackBerry update distribution model you will see that regardless of carrier all updates come from BlackBerry they only gate the out based on carrier for contractual and support reasons. That is why tools like Sachesi are able to do what they do. It is probably well within BlackBerry's ability to push an update out to all devices should that become necessary. They don't have to do a full OS replacement on BB10 but some of the libraries (libc for example) can be quite large. So the size of the update would depend on what needed to be changed. There have been some pretty small OS updates along the way.

[Omnitech]

Also if you examine the BlackBerry update distribution model you will see that regardless of carrier all updates come from BlackBerry they only gate the out based on carrier for contractual and support reasons. That is why tools like Sachesi are able to do what they do. It is probably well within BlackBerry's ability to push an update out to all devices should that become necessary. They don't have to do a full OS replacement on BB10 but some of the libraries (libc for example) can be quite large. So the size of the update would depend on what needed to be changed. There have been some pretty small OS updates along the way.

Since I have never seen any sort of update like that for BB10, are you actually confident that a mechanism for doing that actually exists?

Because those are all on protected storage - I thought they basically had to write things on the block level when doing core OS updates, not file-by-file.

But I'm not a coder and I never bothered to install the dev environment to poke around the OS, so...

[anon(2729369)]

Google is doing the right thing on Android by pushing ChaCha20 and Poly1305.

The benefits of this new cipher suite include:

• Better security: ChaCha20 is immune to padding-oracle attacks, such as the Lucky13, which affect CBC mode as used in TLS. By design, ChaCha20 is also immune to timing attacks. Check out a detailed description of TLS ciphersuites weaknesses in our earlier post.
• Better performance: ChaCha20 and Poly1305 are very fast on mobile and wearable devices, as their designs are able to leverage common CPU instructions, including ARM vector instructions. Poly1305 also saves network bandwidth, since its output is only 16 bytes compared to HMAC-SHA1, which is 20 bytes. This represents a 16% reduction of the TLS network overhead incurred when using older ciphersuites such as RC4-SHA or AES-SHA. The expected acceleration compared to AES-GCM for various platforms is summarized in the chart below.

[anon(2729369)]

Theo de Raadt has stated that the OpenSSL people are irresponsible, and this is why he has put together a team now to fork it.

As much as de Raadt is oftentimes a bit of a crank, in this case my gut says that he's probably right.

As with many forks, such as with libavc, it's a good move to shake the establishment and get things moving again.
OpenSSL now has $3M over the next 3 years to clean up their mess.

[Richard Buckley]

Since I have never seen any sort of update like that for BB10, are you actually confident that a mechanism for doing that actually exists?

Completely.

Because those are all on protected storage - I thought they basically had to write things on the block level when doing core OS updates, not file-by-file.

It is entirely possible to update any system by modifying a file in place using the binary equivalent of patch. But we don't see many changes at the source code level that don't end up moving things around so that isn't practical. However in theory, when Apple had to patch the GotoFail bug they could have fixed it by just changing the machine language branch instruction to a set of NOP (No operation) instructions. Years ago, when compiling large systems took a long time, this was a common way of making changes. Luckily we don't live in those times any more.

The best QNX filesystem for Flash memory is a fully journaled filesystem and doesn't actually have files. The file and directory structure is an artifact created the driver. This allows, among other things, the ability to do wear leveling on parts of the "file system" that don't change. But in any case the storage would not be protected from the system, which would be doing the update.

But I'm not a coder and I never bothered to install the dev environment to poke around the OS, so...

[Richard Buckley]

As with many forks, such as with libavc, it's a good move to shake the establishment and get things moving again.
OpenSSL now has $3M over the next 3 years to clean up their mess.

The Linux Foundation now has $3M over at least the next 3 years to fund critical Open Source infrastructure code maintenance. OpenSSL is the first of several, if not many, project that will benefit from the funding.

[Richard Buckley]

Google is doing the right thing on Android by pushing ChaCha20 and Poly1305.

Djb is a good cryptographer, but of course whether or not this is the "right thing" depends on how long ChaCha20, the underlying Salsa20 and Poly1305 survive without weaknesses being found. There was a time when all of the crypto techniques Google is seeking to replace with these cyphers were the "right thing" to do.

[anon(2729369)]

The Linux Foundation now has $3M over at least the next 3 years to fund critical Open Source infrastructure code maintenance. OpenSSL is the first of several, if not many, project that will benefit from the funding.

Yep, I read too fast.
"As well as maintaining OpenSSL it will also support development of other crucial open-source software."
It's good that they're taking a holistic approach.

Djb is a good cryptographer, but of course whether or not this is the "right thing" depends on how long ChaCha20, the underlying Salsa20 and Poly1305 survive without weaknesses being found. There was a time when all of the crypto techniques Google is seeking to replace with these cyphers were the "right thing" to do.

Agreed. On the plus side, his work is the foundation of "SHA3", so the cipher family's strength and weaknesses should have been thoroughly evaluated and should last 5-10 years with various patches like its predecessors...

[Omnitech]

Completely.


It is entirely possible to update any system by modifying a file in place using the binary equivalent of patch. But we don't see many changes at the source code level that don't end up moving things around so that isn't practical. However in theory, when Apple had to patch the GotoFail bug they could have fixed it by just changing the machine language branch instruction to a set of NOP (No operation) instructions. Years ago, when compiling large systems took a long time, this was a common way of making changes. Luckily we don't live in those times any more.

Of course. I've done my share of updates on various *nix systems including the way FreeBSD traditionally did a full OS upgrade which is re-compile all the binaries including the kernel from sourcecode, ie "buildworld".

I just hadn't seen this happen with BB10 much - the small OTA updates I've seen were mostly (from what I could tell) updates to userland apps, not core OS files. But in retrospect that was silly, if you can update the Android runtime via BlackBerry World there's no reason you couldn't update a different core OS component either that way or pushed OTA.

The main issue for BlackBerry is the carrier-gating of all that stuff. I'm pretty sure a lot of people had unpatched vulns on their BB10 devices for months because they happened to be on a carrier that never pushed the patched version, or they never bothered to update their device. BB10 has had a few serious vulns in Flash and other components. (Including AFAIK a way to gain root via the backup mechanism that happened to be exploited by the guy who wrote Sachesi - but was patched by some build of 10.0.10 or 10.1 and then BlackBerry blacklisted the old OS's so you couldn't re-install them once it had something newer on it. The only successful root exploit I am aware of that ever afflicted BB10. )

[anon(2729369)]

I just hadn't seen this happen with BB10 much - the small OTA updates I've seen were mostly (from what I could tell) updates to userland apps, not core OS files. But in retrospect that was silly, if you can update the Android runtime via BlackBerry World there's no reason you couldn't update a different core OS component either that way or pushed OTA.

A lot of the OTA updates do include changes in the core OS. A new radio could require some changes to the phone service, the camera app could require an updated binary in /bin, etc.
AFAIK, the runtime is a VM (in userland), so it's easy to just push a new "image" from BBW as long as it's in the same branch. I wonder if the one time it happened was as a test or to patch a critical security vulnerability...
It should be possible to update libs, etc. from BBW as well, using internal tools similar to apt-get and to keep the traditional OTA update for a change of branch or radio. Google is doing it across various Android branches with their Play Services.

Note: I've used your definition of userland as I understood it (what is not core), as opposed to the strict definition (what is not in kernel space)

[Superdupont 2_0]

then read what Ivan Ristic has to say about BEAST, you will see that it is not quite as black and white as the cute site would have you believe.

Well, he says "[...] Therefore, BEAST is a serious problem." (equivalent to: "Mission Control, we have electrical fire on board") and then he says in comparison to alternative solutions "[...] both issues were of roughly the same risk.(Low.)" (equivalent to: "Mission Control, we have lost one of the engines. Could you reserve a longer airstrip for us?").
My impression is that Ivan Ristic is trying to express that criminals have too limited resources for BEAST. It would have been interesting to hear his opinion on the router/firewall/network security in hotels/airports/cafes in context with the increasing "automization" in the software world. But to be fair, he concludes "Although I don't believe that the problem is exploitable today, there might be other attack vectors we are not aware of."

I don't know where in the world you are

It's a bit hard to tell. I use mobile devices and hotspots, because I am frequently traveling...classical BB user.

get their hands on the private keys that go with fully signed certificates

Haha, if I would be the head of any Three Letter Agency, I would have told my teams "whatever you are doing at the moment, stop it now and forget about your holidays. We will spend the next two weeks fishing private keys and decrypt traffic like there is no tomorrow." ... I am only speculating, but I could imagine that these days some agency operators are smiling all the way from their offices to their homes.

In fact a much bigger problem that will be an issue for PlayBook owners for the next 18 to 36 months is the lack of OCSP Staplin

The, err, good news is that Playbook owners are not less secure than all other platforms, because most servers will not start support OCSP Staplin in the near future.
It seems to be a problem for literally every internet user, especially for hotspot users. Adam Langely from Google wrote a refreshing blog post on the revocation system (quote: "In short, it doesn't work..."):
https://www.imperialviolet.org/2014/...vchecking.html

However, I have the problem on my radar now and assuming the Playbook will not be patched, I will have to move to a new tablet.
I can wait for Playbook 2 until early 2015, but if it doesn't come, sigh, well, I can spend the money for a new tablet only once

Any browser or TLS application that doesn't check for certificate revokation, or that soft-fails when checking is vulnerable

Actually I don't browse to critical websites when connected to hotspots.
But since you mentioned "TLS application", every time I connect my device to a hotspot my main concern is e-mail traffic, videochats and apps.
As a former BIS user, I accepted/used the NOC as "SSL Proxy" giving my e-mail password away to a third party (= BlackBerry), however, BIS is the transparent exemption.
I have no idea what's actually happening in hotspots, but sometimes the certificate of a hotspot attempts to meddle inside the traffic with my Active Sync (if I interpret the certificate warnings from my ActiveSync Account correctly).
I observed this only on my Playbook and only (when already connected to the Wi-Fi but) before log-in .
I always press the "reject"-button and regard it as some sort of misconfiguration (though my e-mail provider cannot explain it; the reponse from Playbook support also did not bring any light into it).
I might add: Most times the warning doesn't pop up. And it never pops up for my freemail account, only my ActiveSync account has this problem.
Just to round it up:
A few months ago it was found that some apps on Android accept almost every certificate without a warning...it's another story, but underligning that users don't have sufficient control here.
There is also an interesting paper on SSL deficiencies in apps (iOS and Android): http://android-ssl.org/files/p49.pdf

[bbschorsch]

Guys 10.3 addresses that issue and says it's ok using TLS 1.2

Posted via CB10

[anon(2729369)]

Haha, if I would be the head of any Three Letter Agency, I would have told my teams "whatever you are doing at the moment, stop it now and forget about your holidays. We will spend the next two weeks fishing private keys and decrypt traffic like there is no tomorrow." ... I am only speculating, but I could imagine that these days some agency operators are smiling all the way from their offices to their homes.

I just wanted to add that it was hinted that the NSA had known about this bug for months/years. They have several exploits in their treasure chest, ready to use when needed. It's common practice for Black/Grey hats to sell 0-days exploits on the dark net instead of reporting them responsibly. In the case of the NSA, it's a bit troubling for US citizens since they're also supposed to protect US infrastructures, companies, etc.