Android P will require apps to use TLS to encrypt all connections

[Ageless93]

As per https://android-developers.googleblog.com/2018/03/previewing-android-p.html and https://security.googleblog.com/2018/04/protecting-users-with-tls-by-default-in.html

If your app uses TLS for all connections then you have nothing to do. If not, update your app to use TLS to encrypt all connections.
Android considers all networks potentially hostile and so encrypting traffic should be used at all times, for all connections. Mobile devices are especially at risk because they regularly connect to many different networks, such as the Wi-Fi at a coffee shop. All traffic should be encrypted, regardless of content, as any unencrypted connections can be used to inject content, increase attack surface for potentially vulnerable client code, or track the user.

So this will mean that present BOINC for Android won't work under Android 9.

[davidpanderson]

Seems like a problem for projects that don't use HTTPS

…

On Fri, Apr 13, 2018 at 6:15 AM, Jord van der Elst ***@***.*** > wrote: As per https://android-developers.googleblog.com/2018/03/ previewing-android-p.html and https://security.googleblog. com/2018/04/protecting-users-with-tls-by-default-in.html _ If your app uses TLS for all connections then you have nothing to do. If not, update your app to use TLS to encrypt all connections._ *Android considers all networks potentially hostile and so encrypting traffic should be used at all times, for all connections. Mobile devices are especially at risk because they regularly connect to many different networks, such as the Wi-Fi at a coffee shop. All traffic should be encrypted, regardless of content, as any unencrypted connections can be used to inject content, increase attack surface for potentially vulnerable client code, or track the user.* So this will mean that present BOINC for Android won't work under Android 9. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2466>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA8KgYi5ad6J8MEAYc-W8L7kp4PzQmlFks5toKTYgaJpZM4TTbg_> .

[brevilo]

I fail to see any reasonable excuse for not using TLS in 2018. Thus it shouldn't stop us from what we are required to do anyway, e.g. by GDPR.

[BryanQuigley]

Is there any appetite to force HTTPS use from the BOINC/Science United project? It could just be picking two dates:

• On Jan 1st, 2021 - no new projects can be included if they are not HTTPS
• On Jan 1st, 2022 - all projects must be HTTPS to be in the available project lists

You could be easily be much more aggressive, but just creating any minimum is important IMHO.

[BryanQuigley]

Right now we are at 23 projects using HTTPS (including account managers) and 15 only using HTTP.

grep "<url>" all_projects_list.xml | grep http: 
        <url>http://www.rnaworld.de/rnaworld/</url>
        <url>http://asteroidsathome.net/boinc/</url>
        <url>http://www.cosmologyathome.org/</url>
        <url>http://milkyway.cs.rpi.edu/milkyway/</url>
        <url>http://einstein.phys.uwm.edu/</url>
        <url>http://numberfields.asu.edu/NumberFields/</url>
        <url>http://moowrap.net/</url>
        <url>http://www.primegrid.com/</url>
        <url>http://gerasim.boinc.ru/</url>
        <url>http://srbase.my-firewall.org/sr5/</url>
        <url>http://www.rechenkraft.net/yoyo/</url>
        <url>http://www.worldcommunitygrid.org/</url>
        <url>http://boinc.tacc.utexas.edu/</url>
        <url>http://radioactiveathome.org/boinc/</url>
        <url>http://www.gridrepublic.org/</url>
grep "<url>" all_projects_list.xml | grep https: 
        <url>https://www.sidock.si/sidock/</url>
        <url>https://boinc.ibercivis.es/ibercivis/</url>
        <url>https://www.gpugrid.net/</url>
        <url>https://boinc.bakerlab.org/rosetta/</url>
        <url>https://quchempedia.univ-angers.fr/athome/</url>
        <url>https://universeathome.pl/universe/</url>
        <url>https://lhcathome.cern.ch/lhcathome/</url>
        <url>https://boinc.nanohub.org/nanoHUB_at_home/</url>
        <url>https://root.ithena.net/usr/</url>
        <url>https://sech.me/boinc/Amicable/</url>
        <url>https://boinc.progger.info/odlk/</url>
        <url>https://boinc.multi-pool.info/latinsquares/</url>
        <url>https://boinc.thesonntags.com/collatz/</url>
        <url>https://escatter11.fullerton.edu/nfs/</url>
        <url>https://rake.boincfast.ru/rakesearch/</url>
        <url>https://minecraftathome.com/minecrafthome/</url>
        <url>https://climateprediction.net/</url>
        <url>https://csgrid.org/csg/</url>
        <url>https://mindmodeling.org/</url>
        <url>https://www.mlcathome.org/mlcathome/</url>
        <url>https://bam.boincstats.com/</url>
        <url>https://scienceunited.org/</url>
        <url>https://grcpool.com</url>```

[BryanQuigley]

I didn't check all of them, but I could find one that if you go to /get_project_config.php and look for web_rpc_url_base it isn't using HTTPS.

Ex: https://milkyway.cs.rpi.edu/milkyway/get_project_config.php

I think the majority of projects can just change their master_url to https and they are already mostly good?

[AenBleidd]

I don't see that we still need to do something here.
If any project doesn't use HTTPS - there is nothing we can do from our side, and since this is a security risk for our users - I don't see a reason to make any exceptions.

However, there is one potential issue that I see here: we have a feature to allow connect from remote BOINC Manager to our Android client.
And we currently do this is a non-encrypted way.
Unfortunately, we can't encrypt this connection since it's a application-to-application connection, and it's not possible to generate certificate for the BOINC Client located on the Android device, fix it to the particular IP and later use it as a secure connection in remote BOINC Manager.
Currently, I see no issues with this on any modern Android device, and looks like that these types of connections a still allowed (I assume, because of the reason I explain above).

Thus, I think we can close this ticket without any changes to the codebase.