Hiden encrypted HTTPS connections to Blackberry servers

Hello

When I look at tcpdump output I can see that there are a bunch of background connections are made by the blackberry. One of them is HTTP and I can see it's probably just to check that my wi-fi connection works and we're connected to the internet. There is no special data transmitted there.

But 3 other connections are using TLS and thus I can't see the data being transmitted. The DNS lookups made by the device go to icc.blackberry.com and inet.icrs.blackberry.com. Behind that are CNAMEs to eu.icrs.dyn.blackberry.net here in Germany, which is 178.239.90.160. The other two TLS connections I'm not sure which domain name is behind, but the IPs belong to blackberry, too. They are: 74.82.89.17 and 93.186.27.162

I'd like to know what is being transmitted, why and how to turn it off.

Thanks

Well, BBM is connected permanently, then there is BlackBerry World update notifications, BlackBerry Protect needs another connection and the time server is another one. If you really want to, you might block them in your router firewall. For mobile data you would need to use a VPN or something like that. Or get BES12, I guess it can be blocked there as well.

Via Pasta CB10

I guess I could disable blackberry protect. But I didn't find a way to disable BBM and Blackberry World updates (also on wi-fi). Is it not possible?

The question is why would you want to disable them? Just because there's a connection doesn't mean there's something sinister behind it.

Posted via CB10

If you disabled it your phone will not be secured anymore.

Posted via CB10

Originally Posted by rthonpm

The question is why would you want to disable them?

Just to test if the connections disappear. Then we know what their purpose is.

I would welcome if RIM could document the connections, their purposes and the services behind a device uses in background in a technical whitepaper. Transparency is a fundamental part of privacy and reduces a lot of suspiciousness.

I don't know but I don't think there is anything suspicious with that. You know that you always have stuffs required update/notification. BlackBerry would be the last mobile phone company in the world that I have a doubt about these types of things.

Posted via CB10

My main motivator was that I am trying to improve my battery runtime. On the other hand I really would like to know what is being transmitted and for what reason.

I am not paranoid about security and try to physically secure my stuff anyways. I don't care about stolen devices getting unusable. To be honest when the device is gone it's gone, can't prevent that with software.
I wanted a hardware keyboard, and I prefer hard security over soft security :P

There's nothing on the phone to compromise me either.

I don't consider the connections "suspicious", I consider them badly documented and possibly useless. I don't use BBM and have disabled it in parental controls and I don't want any updates to be downloaded without my consent (not because I'm worried about security, but because updates often break things). I like to have choice.

It should be more energy efficient to have *one* long-running IP tunnel that fails over from wi-fi to mobile networks. Then the inner tcp endpoints could stay the same and we wouldn't need to redo all those tcp setup and tls handshakes for *multiple* connections every few minutes. Instead we would have one or even three tcp setups and tls negotiations after booting the device (hopefully with a toggle to switch it on only for services we'd like to use) but after that only one keepalive packet for the whole outer tunnel. The device could auto-learn the minimum keepalive time required by the NAT dependent on the wi-fi network or APN in case of mobile networks and try to minimize battery usage by only sending stuff when it's needed.

Knowing people with older blackberry devices and how efficient they are in terms of battery runtime I was shocked not to find any such techniques on my q10 and the battery lasting only a day.

Originally Posted by muellerto

Just to test if the connections disappear. Then we know what their purpose is.

I would welcome if RIM could document the connections, their purposes and the services behind a device uses in background in a technical whitepaper. Transparency is a fundamental part of privacy and reduces a lot of suspiciousness.

full ack

argh. i can't post my reply cause it contains links :(

googling around i found this document: support.blackberry.com/kb/articleDetail?articleNumber=000036470
i find a resemblance at least for the http request to icc.blackberry.com/v1/wifi/.
all the other domains are not being looked up so far by my device. seems like the document might be outdated.

instead i found one more that hasn't been mentioned yet: a http request to www.blackberry.com/app_includes/ccl/v1/cclagentv

there's also some pinging of my gateway every now and then.

in total it seems like the tls connections are at least rather long running when you stay at one location and the tcp connections don't break. that was my biggest battery drainage concern. Still it might be a problem if you roam around a lot between different wifi networks or you loose either wifi or mobile data connection rather frequently due to bad coverage.

a lot of traffic here seems avoidable, a waste of packets to me: many redundant parallel connections that need to be kept alive.

Originally Posted by LeeU1911

I don't know but I don't think there is anything suspicious with that. You know that you always have stuffs required update/notification. BlackBerry would be the last mobile phone company in the world that I have a doubt about these types of things.

Yes, sure, we are on the same side. But that's exactly the reason why they could easily document it: "Look, we have nothing to hide." This kind of marketing should they use.

I'm sure it's nothing to worry about. Albeit if android or iOS were doing the same you can bet your assss people on these forums would be trashing them instead of being so passive.

Posted via CB10

Originally Posted by iamaclevergirl

Knowing people with older blackberry devices and how efficient they are in terms of battery runtime I was shocked not to find any such techniques on my q10 and the battery lasting only a day.

Hey, my Z30 lasts almost up to 4 (!) days. I have two IMAP accounts in Push mode and of course BBM permanently running. OK, I cut my network connections over night.

Note: I tested several traffic monitoring apps and many of them showed the same behavior - when you switch off network connections the energy consume of those apps raises a lot. This is something nobody expects but you can prove this in the Device Monitor. I use Usage Pro now, this works well.

Originally Posted by iamaclevergirl

argh. i can't post my reply cause it contains links :(

It's because you're a new member and it's designed that way to prevent spam. You'll be able to post soon enough once you're more active in these forums.

Posted via my  PassportSQW100-1/10.3.2.2639 or  Z30STA100-5/10.3.1.2558

One of the reasons legacy BBOS phones are so energy efficient is the SIP protocol that BlackBerry uses on that OS. It is a tunnel between the phone and BlackBerry servers (in the case of BIS) and the phone and the corporate BES via BlackBerry servers (in the case of BES). This was a very efficient communication protocol, but was only encrypted for BES, so for BIS it wasn't secure, although a lot of people thought it was.

Back in those days BlackBerry or RIM wasn't just about all things security, they were also all about efficiency. Efficient use of power, efficient use of memory, efficient use of bandwidth. But just like most people aren't willing to put up with what needs to be done for good security, most people aren't willing to put up with the sacrifices needed for that kind of efficiency. Even in BBOS 6 and 7 BlackBerrys used a Webkit based browser which was not as efficient as the BBOS browser because people wanted function over efficiency.

You can't really have a TCP connection fail over from a Wi-Fi network to a wireless network without special support on each end. It is roughly the same problem as bonding two separate ISP connections together to provide higher throughput and better reliability. That's why RIM used the SIP protocol on wireless, and carried the SIP traffic on HTTPS on Wi-Fi connections when they added Wi-Fi capability. With that special support they could do all the things you want your BB10 device to do. But many major carriers were not interested in supporting BB10 on BIS/BES.

LeapSTR100-2/10.3.2.2876

I don't see what's so special about SIP. As you say it's just a protocol. I think with regular tunneling you can create an implementation that handles multiple tls connections just as efficiently as it would be to rewrite all the applications to use SIP for their communication needs. It's about minimizing the amount of connection setups and crypto negotiations while making sure that even high numbers of parallel long-running connections don't create more traffic than one single connection would need. Tunneling solves this in a very trivial way.

Not coming from a mobile background I'm surprised that here where the power requirements are higher people still don't employ such techniques even though all these popular apps are eating so much useless background traffic without it.

At least for the services I concerned myself earlier in this thread all connections terminate on blackberry servers, so it should be possible for them to just provide a tunnel endpoint instead of having multiple connections do the same things in parallel. Obviously they have enough control over the device to implement the other side, too :)

This doesn't require ISP participation. I suggest it *because* it makes the ISP become irrelevant. All we would then need to care about is whether a certain IP connection is up and stable or not and according to this route via one or the other tunnel interface.

An easier solution might of course be to allow me to disable these connections altogether :P

I did figure out that 93-186-28-114.rdns.blackberry.net.https belongs to blackberry protect, because there's some leakage in the certificate negotiation process apparently (but i'm no tls expert, no idea if that's critical in any way).

Originally Posted by iamaclevergirl

I don't see what's so special about SIP. As you say it's just a protocol. I think with regular tunneling you can create an implementation that handles multiple tls connections just as efficiently as it would be to rewrite all the applications to use SIP for their communication needs. It's about minimizing the amount of connection setups and crypto negotiations while making sure that even high numbers of parallel long-running connections don't create more traffic than one single connection would need. Tunneling solves this in a very trivial way.

Well TCP is just a protocol. Yes BlackBerry could implement a tunnelling protocol between BB10 devices and their servers and provide this service. they did that for BBOS, called it SIP, and charged about $US5 per month for the service. The Major carriers did not want to continue to participate so BlackBerry had to come up with a different way to service BB10 devices.

Not coming from a mobile background I'm surprised that here where the power requirements are higher people still don't employ such techniques even though all these popular apps are eating so much useless background traffic without it.

People want apps, essentially for free. So app providers have to monitize through adds, or other strategies (data mining, etc). These strategies are not compatible with a system that tunnels all data through servers that belong to a company that will not monitize their customers data. I'm not suggesting that anyone has made this choice deliberatly, but most smartphone users don't understand the trade-offs involved.

At least for the services I concerned myself earlier in this thread all connections terminate on blackberry servers, so it should be possible for them to just provide a tunnel endpoint instead of having multiple connections do the same things in parallel. Obviously they have enough control over the device to implement the other side, too :)

This doesn't require ISP participation. I suggest it *because* it makes the ISP become irrelevant. All we would then need to care about is whether a certain IP connection is up and stable or not and according to this route via one or the other tunnel interface.

Not with plain TCP/IP. I'm sitting at home using Wi-Fi so my packtes go through my provider's private network to where they interface with the backbone network connecting Autonomous Systems, which happens to be the Toronto area. If I leave home the phone transitions to wireless and packets start going through a completely different private network until they reach where my wireless provider connects to the backbone. In this case Montreal. This is accomplished by a change in the publicly visible IP address my phone is using. If I enter a coffee shop and connect to their Wi-Fi there is yet another provider, private network and backbone connection.There is no facility in TCP/IP to accomplish an enpoint change. If co-operating endpoints want to make this happen using only TCP/IP they can do it, but it still requires the overall bearer tunnel to be torn down and re-established over the new network. OpenVPN can do this quite well, but OpenVPN is notoriously bad in mobile environments because of the power and bandwith consumption needed to manage the tunnel in this way. OpenVPN in the mobile world is another example where people have chosen free and convenient over efficient and at a cost. BB10 does provide an facility to do this efficiently using an IPSec tunnel. If you enable VPN connection on all Wi-Fi and wireless connections then the IPSec protocol will do all that you ask and more efficiently than a TCP/IP tunnel, but still less efficiently than the way things are handled now.

BlackBerry, as RIM, was able to do this very efficiently with SIP, because on wireless SIP uses a BlackBerry (RIM) node that is deep inside the wireless cariers front end and gets the phone data packets before they are being carried by TCP/IP. In fact using SIP to connnect to BES required crypto set up only on initial connection and when one end, or the other re-booted. All other cryptographic housekeeping was in the form of symetric key wear monitoring and symetric key replacement which is very efficient in computation, power, and bandwidth. Under BIS or BES an appliction could establish a TLS connection from the phone to any server, but this was quite noticable in power consumption and bandwidth usage.

An easier solution might of course be to allow me to disable these connections altogether :P

True indeed.

I did figure out that 93-186-28-114.rdns.blackberry.net.https belongs to blackberry protect, because there's some leakage in the certificate negotiation process apparently (but i'm no tls expert, no idea if that's critical in any way).

Hey, thanks for your long answer.

i think we might be talking about a different kind of SIP. I know SIP only from voip and IM (possibly including BBM).

Anyways, disregarding the technical details of openVPN vs. IPSEC vs. TLS and UDP vs. TCP vs IP-layer tunnels, you do seem to agree that with the right tunneling a power-efficient handover from one to the other network (AS) doesn't need to affect the inner tcp connections.

On all modern phones including blackberry this is not utilized any more. Even in the base install without any apps or PIM accounts added to the device it wastes useless energy maintaining connections and checking for connectivity all the time. I count multiple parallel connections that each get active every 5 minutes. One of them doing a whole TCP setup *every single time*

I see your point about blackberry not liking that users want their service for free. But what they deliver for free seems to me like some android-level absurdity.

Now if I were to deploy my own IPSEC tunnel, unless I can tune the keepalive settings and polling intervals of these hidden blackberry services that are always running in the background I won't get any power saving benefit while my devices are stationary and in standby.
Second issue is that many mobile providers won't even allow IPSEC on their networks. That's why I got into a habit of tunneling everything via TLS on port 443. This has so far worked with every single provider I've tried out, both very restrictive company wi-fis and mobile operators. I don't think it's much of an overhead, even though in the worst case you'll have tcp in tcp and it might affect your throughput and delay/jitter a bit I hardly notice the effects in my regular usage scenarios. The stability I get from it far outweighs the small overhead.

Originally Posted by iamaclevergirl

When I look at tcpdump output I can see that there are a bunch of background connections are made by the blackberry

Please provide the steps to do this so I can see them on mine, too.

Sorry you are correct, not SIP but SRP. Must have SIP on my mind and the fingers are going there by themselves, LOL.

Unfortunately this Wikipeadia article is a bit misleading due to the lack of information widely available outside of NDA channels:
https://en.wikipedia.org/wiki/Server_Routing_Protocol

Originally Posted by iamaclevergirl

Hey, thanks for your long answer.

i think we might be talking about a different kind of SIP. I know SIP only from voip and IM (possibly including BBM).

Anyways, disregarding the technical details of openVPN vs. IPSEC vs. TLS and UDP vs. TCP vs IP-layer tunnels, you do seem to agree that with the right tunneling a power-efficient handover from one to the other network (AS) doesn't need to affect the inner tcp connections.

On all modern phones including blackberry this is not utilized any more. Even in the base install without any apps or PIM accounts added to the device it wastes useless energy maintaining connections and checking for connectivity all the time. I count multiple parallel connections that each get active every 5 minutes. One of them doing a whole TCP setup *every single time*

I see your point about blackberry not liking that users want their service for free. But what they deliver for free seems to me like some android-level absurdity.

Now if I were to deploy my own IPSEC tunnel, unless I can tune the keepalive settings and polling intervals of these hidden blackberry services that are always running in the background I won't get any power saving benefit while my devices are stationary and in standby.
Second issue is that many mobile providers won't even allow IPSEC on their networks. That's why I got into a habit of tunneling everything via TLS on port 443. This has so far worked with every single provider I've tried out, both very restrictive company wi-fis and mobile operators. I don't think it's much of an overhead, even though in the worst case you'll have tcp in tcp and it might affect your throughput and delay/jitter a bit I hardly notice the effects in my regular usage scenarios. The stability I get from it far outweighs the small overhead.

Certainly if you tunnel from a client (phone, pc, whatever) to a fixed system on the internet, and maintain that tunnel accross network changes (mobility), then any protocol carried on that tunnel can be fooled to believe it is always connected, but that the connection is just sometimes really slow. I set up some systems with this kind of function in the days before widespread internet availability. To carry this to the ultimate you have to modify the semantics that a TCP connection expects for things like keep-alive and polling. This is very difficult to get right in every case especially if you have to support whatever random

On the phone side in BBOS BlackBerry accomplised this with control over the netwrok access libraries. If you were using BES/BIS you could request whatever keepalive settings you wanted, but the RIM network servers or the BES server would simply use the settings that they wanted. They used the same techniqe to mediate network outages, or phones moving out of coverage. This is where the power of the BlackBerry node in the forward segment of the mobile network comes in. It would be informed by the carrier network when a phone was on the network or not. So a BlackBerry could receive push email even if it was only on the network for a frew secods as the user's car crested a hill. Polling in this environment put your application at a huge disadvantage when compared to BlackBerry push. This is both less important now, because of better networks, and not desired because it moves all the data between the phone and the internet through BlackBerry network servers. BlackBerry pays the data charges for everything that moves by BES or BIS twice. Once between the internet and BlackBerry, and once between BlackBerry and the phone. Can you imagine what it would cost BlackBerry to have event their current tiny user base watching Netflix under this system? In the final years before the release of BB10 developers were looking for more capability to replicate the Android and iOS way of doing things on BlackBerry. On BB10 they got it.

So, while BlackBerry, Google, Apple or Microsoft could all set up a tunnelling system, and BlackBerry still maintains one, only an extreamly small market wants the service, and an even smaller market is willing to pay for it.

Originally Posted by TheAuthority

Please provide the steps to do this so I can see them on mine, too.

On my internet router I ran tcpdump -i eth0 host q10 -A -s0
with eth0 being my internet facing interface and q10 the hostname of my bb.

^Thank you.

(I don't know what's up with this forum, but sometimes there's no "thanks" button.)