new icon plus tls notes

.idea/compiler.xml

@@ -0,0 +1,6 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<project version="4">
+  <component name="CompilerConfiguration">
+    <bytecodeTargetLevel target="1.8" />
+  </component>
+</project>

.idea/gradle.xml

@@ -15,6 +15,7 @@
           </set>
         </option>
         <option name="resolveModulePerSourceSet" value="false" />
+        <option name="useQualifiedModuleNames" value="true" />
       </GradleProjectSettings>
     </option>
   </component>

.idea/misc.xml

@@ -1,6 +1,6 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <project version="4">
-  <component name="ProjectRootManager" version="2" languageLevel="JDK_1_8" project-jdk-name="1.8" project-jdk-type="JavaSDK">
+  <component name="ProjectRootManager" version="2" languageLevel="JDK_1_8" default="true" project-jdk-name="1.8" project-jdk-type="JavaSDK">
     <output url="file://$PROJECT_DIR$/build/classes" />
   </component>
   <component name="ProjectType">

README.md

@@ -6,3 +6,48 @@ A Gemini protocol browser for Android based OS
 
 See the project page on Öppenlab.net for latest download: [oppenlab.net/pr/ariane](https://oppenlab.net/pr/ariane/)
 
+## TLS
+
+**Note: Arianne does NOT currently implement TLS, this means some pages in Geminispace may not be available.**
+
+From the [Gemini specification](https://gemini.circumlunar.space/docs/specification.html):
+
+> Use of TLS for Gemini transactions is mandatory.  
+> Use of the Server Name Indication (SNI) extension to TLS is also mandatory, to facilitate name-based virtual hosting.
+
+Ariane will skip TLS validation until client certs are working, this will mean all Gemini content will be available sooner, then we can implement TOFU later:
+
+> Clients can validate TLS connections however they like (including not at all) but the strongly RECOMMENDED approach is to implement a lightweight "TOFU" certificate-pinning system which treats self-signed certificates as first- class citizens
+
+### Client TLS
+
+> Although rarely seen on the web, TLS permits clients to identify themselves to servers using certificates
+
+From the spec:
+
+
+* Short-lived client certificates which are generated on demand and deleted immediately after use can be used as "session identifiers" to maintain server-side state for applications. In this role, client certificates act as a substitute for HTTP cookies, but unlike cookies they are generated voluntarily by the client, and once the client deletes a certificate and its matching key, the server cannot possibly "resurrect" the same value later (unlike so-called "super cookies").
+* Long-lived client certificates can reliably identify a user to a multi-user application without the need for passwords which may be brute-forced. Even a stolen database table mapping certificate hashes to user identities is not a security risk, as rainbow tables for certificates are not feasible.
+* Self-hosted, single-user applications can be easily and reliably secured in a manner familiar from OpenSSH: the user generates a self-signed certificate and adds its hash to a server-side list of permitted certificates, analogous to the .authorized_keys file for SSH).
+
+This suggests it'd be useful for a client to offer both a long-lived 'identity' cert, and short-lived anonymous certs to offer a (real) incognito mode - a session cert.  
+
+A key sentence in the spec:
+
+> Gemini requests will typically be made without a client certificate.
+
+Client certs should only be required for protected content:
+
+> Gemini requests will typically be made without a client certificate. If a requested resource requires a client certificate and one is not included in a request, the server can respond with a status code of 60, 61 or 62 (see Appendix 1 below for a description of all status codes related to client certificates). A client certificate which is generated or loaded in response to such a status code has its scope bound to the same hostname as the request URL and to all paths below the path of the request URL path. E.g. if a request for gemini://example.com/foo returns status 60 and the user chooses to generate a new client certificate in response to this, that same certificate should be used for subsequent requests to gemini://example.com/foo, gemini://example.com/foo/bar/, gemini://example.com/foo/bar/baz, etc., until such time as the user decides to delete the certificate or to temporarily deactivate it. Interactive clients for human users are strongly recommended to make such actions easy and to generally give users full control over the use of client certificates.
+
+From this it's clear general requests should NOT use a client cert (to protect user identity if nothing else), if a server requests a client cert we should offer various configuations:
+
+* Always use identity cert
+* Always use a fresh session cert
+* Prompt user
+
+That's it as far as the spec is concered, the rest is down to the Android API
+
+## Android TLS
+
+* [SSLSocket](https://developer.android.com/reference/javax/net/ssl/SSLSocket)

app/src/main/AndroidManifest.xml

@@ -8,9 +8,9 @@
     <application
         android:name="oppen.ariane.Ariane"
         android:allowBackup="true"
-        android:icon="@drawable/vector_app_icon"
+        android:icon="@drawable/vector_ariane"
         android:label="@string/app_name"
-        android:roundIcon="@drawable/vector_app_icon"
+        android:roundIcon="@drawable/vector_ariane"
         android:supportsRtl="true"
         android:theme="@style/AppTheme"
         android:networkSecurityConfig="@xml/network_security_config">