daneren2005 / Subsonic

Home of the DSub Android client fork
GNU General Public License v3.0
574 stars 162 forks source link

Self Signed Certificate Keystore #60

Open daneren2005 opened 11 years ago

daneren2005 commented 11 years ago

Currently all self-signed certificates are accepted. On the first acceptance of a self-signed certificate for a given domain it needs to be saved on either the device keystore if accessible, or on a app specific one if nothing else. There also needs to be a way to clear it in case the self-signed certificate or domain changes.

daneren2005 commented 10 years ago

Possible starting point https://gitlab.com/fdroid/fdroidclient/blob/master/src/org/fdroid/fdroid/FDroidCertPins.java https://github.com/binaryparadox/AndroidPinning https://github.com/ge0rg/MemorizingTrustManager

daneren2005 commented 10 years ago

https://github.com/koush/ion

daneren2005 commented 9 years ago

https://github.com/ge0rg/MemorizingTrustManager

onetimeburner commented 9 years ago

You could provide the ability to hand-key the certificate's SHA1 fingerprint? : )

ultramancool commented 9 years ago

If you could just provide a way to disable the self-signed allowance, that'd be good. I install my own CA cert onto my devices, but realized that DSub worked without this. Allow self-signed should be a checkbox at least.

precurse commented 5 years ago

I've been using DSub for a while with my Subsonic setup with a valid Root-CA cert. My certificate expired the other day and noticed that DSub continued to connect without any warnings or errors.

I then proceeded to test to see how it handled self-signed certificates. It appears there is NO certificate checking done at all. Any server certificate is accepted by the DSub client, which means any MITM (Man-in-the-middle) TLS attack can be carried out trivially and credentials stolen.

Other Subsonic clients that I tested off the Play Store seem to do this CA check properly. Please fix! I have a test installation that you can use to verify if needed.

OS-WS commented 3 years ago

Hi @daneren2005 , Was this issue ever addressed?

by the way, this issue was assigned with CVE-2018-1000664 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-1000664