Open GoogleCodeExporter opened 8 years ago
This would indeed be the most preferable situation. I will have to look into
how this
stuff works, but I will do that in the future since it is the logical solution
to all
SSL problems (like issue 120).
Original comment by erickok@gmail.com
on 6 Apr 2010 at 9:09
Original comment by erickok@gmail.com
on 6 Apr 2010 at 9:09
I modified the FakeTrustManager class to permit checking a certificate's
thumbprint against a known, user-defined value. It works for me on my
self-signed certificate ssl tunneled copy of uTorrent.
Possible issues that could arise are:
* The XirvikSettings and SeedM8Settings class had to be updated to pass the correct arguments to DaemonSettings. At the moment it just passes null for the new sslKey value. I do not know what they do or how they should behave.
* If there are connections to different servers within the same set of host settings (its configured per host). It will fail as the thumbprints won't match. I don't know if this happens in the design of the application at this time.
I hope you find this useful.
Thanks.
--
Danny.
The mind of the believer stagnates. It fails to grow outward into an
unlimited, infinite universe.
-Frank Herbert
Original comment by dekim...@gmail.com
on 18 Sep 2010 at 8:35
Attachments:
Thanks a lot for your contribution! I will try to test this later this week.
The XirvikSettings and SeedM8Settings classes are use for seedbox support and
will not need a specific (self-signed) SSl certificate.
Original comment by erickok@gmail.com
on 20 Sep 2010 at 1:53
A more userfriendly way to go about it would be to have it prompt the user the
first time it encounters the certificate. Ask them if they want to accept and
remember this certificate for futute connections. Kinda how the ssh client
behaves. This implementation was far easier to hammer out quickly. Albeit it is
a tad crude. :D
I do not know how secure an ssl cert's thumbprint would be. I believe it is
reasonably secure, but I.do not know for certain.
Additonally my code does not verify the distinguished name on the certificate.
I'm not sure if Java does this, I have not tested.
It also assumes there is only one certificate in the cert chain.
That's all the gotchas I can think of at the moment.
Original comment by dekim...@gmail.com
on 20 Sep 2010 at 3:44
I'm not sure about the proposed solution but I like the possibility to "accept
and remember" a self signed certificate and ask again if the certificate
changes (to protect against man in the middle attacks).
Original comment by bigras.b...@gmail.com
on 20 Sep 2010 at 9:04
Although I agree with you both that it would be best to ask the user to 'accept
and remember', I have added this patch so users can at least use SSL
thumbprint-based certificate checking. (See r276)
Thanks a lot for your patch! I will add that 'accept and remember' feature
later.
Original comment by erickok@gmail.com
on 24 Sep 2010 at 9:11
Just an FYI for people looking on how to do this, you should find out the SHA1
fingerprint of your cert. You can find that by double clicking on the lock in
the bottom right corner of Firefox while you are at your webgui and choosing
"view certificate". Copy the SHA-1 fingerprint, but replace the : with <space>
characters. You see this in FF:
AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA
you type this into transdroid:
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
(Length approximate, it's the longer of the two fingerprints)
Original comment by randall....@gmail.com
on 4 Feb 2011 at 1:06
I hope this helps someone else not have to type the hash twice and install a
barcode keyboard:
Note that the android releases before 3.0 don't support SNI through the
library/api that transdroid is currently using. Depending on how you set-up
your server you might always get the default certificate instead of the one
used in your browser. Typing in the sha-1 hash/fingerprint/thumbprint of that
certificate should work in that case.
It's not that big of a deal if you can trust both certs and you know what
you're doing.
N.B. I wish the entry field was more explanatory (ie. is it sha-1 or md5, etc.)
Original comment by srdjan.r...@gmail.com
on 12 Oct 2011 at 8:32
I second that, the field should be way more explanatory!
I first tried the SHA-1 fingerprint, but with ':' inbetween. Didn't work. So I
tried the MD5, same thing didn't work. So I had to use google to find out one
has to use whitespaces instead of ':'
This should be noted on the app itself somehow! Other than this, great
submission!
Original comment by frazzz...@gmail.com
on 25 Feb 2012 at 9:44
This patch incorporates the changes requested:
* Permitting any (or none) separators in the field.
* Adding that the field is using SHA-1.
NOTE: I don't have an android dev environment right now so I wasn't able to
test. But these are each rather small (1-line) changes.
Original comment by dekim...@gmail.com
on 19 Mar 2012 at 4:12
Attachments:
Thanks! Added in raaebce373c7d.
Original comment by erickok@gmail.com
on 21 Mar 2012 at 9:23
Version 1.6 seems to have broken custom SSL. Accept all still works, as does
manually reverting to the old version. Using deluge tunneled through apache
(reverse proxy).
Original comment by vectorfe...@gmail.com
on 29 Aug 2012 at 7:03
Hmm I didn't change anything in 1.1.6 relating to the SSL handling... Accepting
all certificates works, with the same other settings? I did change Deluge's
settings handling. Deluge now has a separate web interface password setting on
top of the (optional) http authentication username and password.
Original comment by erickok@gmail.com
on 29 Aug 2012 at 9:26
| Version 1.6 seems to have broken custom SSL.
| Accept all still works, as does manually
| reverting to the old version.
Same thing for me. Using rtorrent 0.9.2/libtorrent 0.13.2
Works ok with custom fingerprint on transdroid 1.1.4 , not working in 1.1.6 (I
don't have 1.1.5 so don't know if it works/was actually related)
For everything else this app is wonderful!
Original comment by fabio.al...@gmail.com
on 31 Aug 2012 at 4:49
I might have found the problem.
Check out the patch file 124.patch
> replaceAll("[^a-f0-9]+", "");
should be:
> replaceAll("[^a-fA-F0-9]+", "");
or it will remove also all the upper case letters (that's why it wasn't working
for me).
So if you have 1.1.6 replace all uppercase to lowercase in your thumbprint and
it will work.
For current devel version please see attached patch.
Thanks again for the excellent work!
Original comment by fabio.al...@gmail.com
on 1 Sep 2012 at 3:21
Attachments:
Wow, that was a good find... Thanks! See rfa98b5bb5624.
Original comment by erickok@gmail.com
on 1 Sep 2012 at 9:49
Original issue reported on code.google.com by
bigras.b...@gmail.com
on 5 Apr 2010 at 11:52