HTTP server on Android

[t2ym]

HTTP server on Android

Status - Preliminary Research

Goal: Serve a charged web app from an Android app distributed via Google Play

• Pros
  • No need to maintain customer information on payment and web app projects on cloud servers
    • Payment information is controlled by Google Play
    • All information on customers' web app projects in development is confined to the intranet for the dev teams
  • No need to maintain scalable cloud servers on the internet (low-cost)
    • Scalable (if so designed)
      • Expandable to constitute a dedicated mini cluster of Android devices with the app
  • Automatic updating
• Cons
  • Customers (web app developers) have to configure the Android app as an intranet web server
    • Easy one-time tasks for web developers
      • Fixed IP address has to be assigned to each Android device for the app
      • TLS certificates for development have to be generated and installed onto the Android app
      • Development consoles (PCs) have to point the web server as an internal host name (https://thin-hook.intranet:8443) with /etc/hosts
  • The Android app has to be protected from cracking (research in progress)
• Why Android? Why not Microsoft Store?
  • Recent Android devices have hardware-backed keystores, which should HOPEFULLY be useful for maintaining purchase information securely
  • Decent Android devices have enough performance for serving web apps to rich clients

Priliminary Experiments

HTTP Server types on Android

Type 1: nghttp2 1.43.0 (native process with threading)

• Example server: nghttp2/examples/asio-sv.cc (Boost-based asynchronous I/O processing)
  • Dependencies built for arm64 with Android NDK r21e
    • Several tricks for building
  • Statically linked as an arm64 binary (including openssl static library)
    • Shared library build crashes (under investigation)
  • Launch from an Android app
    • Renamed to libasio-sv.so and embedded to APK
      • SELinux policy for Android 10 and later does not allow execution of binaries under the files/ folder
      • SELinux policy for Android 10 and later does not allow modification of lib*.so binaries expanded from APK
      • SELinux policy for Android 10 and later allows exectution and dynamic loading (execute access vector) only for the expanded library folder
      • APK does not allow names of native ELF binaries other than libXX.so
    • From Android Service via ProcessBuilder
    • With WakeLock
  • Raw performance of "Hello, World" response via HTTP/2 (https)
    • ~22,000 req/sec with 8 threads on Snapdragon 730G (2 * 2.2GHz, 6 * 1.8GHz cores: Pixel 4a)
  • Port integrityService

Type 2: node 14.16.1 (JavaScript on a native node process)

• express on node 14.16.1
  • Built for arm64 with Android NDK r21e
    • A few tricks for building
    • The node binary from Termux is inapplicable as it is linked to different shared libraries
  • Statically linked as an arm64 binary
    • Statically linked except for libc++_shared.so
  • Launch from an Android app
    • Renamed to libnode.so and embedded to APK
    • From Android Service via ProcessBuilder
    • Unzip NPM project image in Android assets
    • With WakeLock
  • Raw performance of "Hello, World" express app via HTTP/1.1 (https)
    • ~3,000 req/sec with 4 worker processes on Snapdragon 730G (2 * 2.2GHz, 6 * 1.8GHz cores: Pixel 4a)
  • Building native NPM modules - under investigation
    • If ConnectV2 record is implemented, there is no need to process RSA OAEP with SHA256 in a native NPM module

Type 3: nanohttpd (Java library with threading) - planning

Type 4: cpp-httplib (C++ library with threading) - planning

Interfacing between the Android app and the HTTP server

Type 1: localhost HTTPS

• okhttp3 to access localhost "Hello, World"

Type 2: UNIX socket

Type 3: NDK Binder IPC (seems to be impossible for native non-system-service processes; only for libraries)

• Service registration via NDK Binder API in C++ is under investigation

Type 4: stdin/stdout for the HTTP server process

• Capture stdout/stderr of the HTTP server process

Triple Encryption for protecting proprietary code

• No private keys on the HTTP server side
  • Enhance the integrity service protocol
    • ConnectV2 request - Servers without private keys can handle connection
    • Pending response - Trigger downloading "Browser Validation Pack" for a latest browser and let the browser wait
    • x-content-encoding: double-aes-256-gcm+gzip
• Exclude open-sourced code
• Encrypt service worker caches
  • With keys derived from ClientIntegrity + random bits
• "Browser Validation Packs" have to be distributed effectively for latest Chrome browsers
  • Via Google Play as app features
  • Via GitHub releases (for hasty users)
  • Automatic generation of "Browser Validation Packs" to publish
    • Integrate automated validation service with the automatic generation

Other research items

TBD