<div dir="ltr">Hi,<div><br></div><div>I have a couple of suggestions on it.</div><div>First of all I would like to know how packages are distributed in kubuntu, may be we could add a "check for update" button in kubuntu version of application.</div><div><br></div><div>Or we could provide a link to old version of android application which does not support ssl on application page of playstore.</div><div><br></div><div>Or the best one is to include "isSSLSupported" in identity package and have a separate backend implementation for ssl and normal version, this would be little difficult because simple socket can't connect to ssl server sockets due to difference in protocols they follow, but it is achievable(May be we need a SSLLanLink, SSLanLinkProvider and split Device into two, i.e normal Device and SSLDevice). </div><div><br></div><div>I will further dig into it.</div><div><br></div><div>Vineet Garg</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 7, 2015 at 9:05 AM, Albert Vaca <span dir="ltr"><<a href="mailto:albertvaka@gmail.com" target="_blank">albertvaka@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I like your proposal and even though I'm not really into security and<br>
will need a second pair of eyes to review it, I'm sure it would be a<br>
nice GSOC proposal. I believe this is one of the most important things<br>
missing in KDE Connect right now and I'm actually waiting for this to<br>
happen before releasing a "1.0" version.<br>
<br>
There is one thing, though, that I would like you to take into<br>
account, and it is retro-compatibility. I think that we can implement<br>
a brand new protocol in the next (Plasma) version of KDE Connect, and<br>
just remove the old implementation, but for Android I would like to<br>
have support for both versions of the protocol at the same time (and,<br>
hence, a way to determine which one to use). The reason is that, since<br>
we can update the Android app very fast (people will get notified on<br>
their phones and they will just need to press a button), desktop users<br>
are usually tied to distribution releases, and they might be stuck<br>
with an old version of KDE Connect for long.<br>
<br>
Then, my goal would be that, regardless of the version of KDE Connect<br>
you have on your desktop, your phone should always be compatible with<br>
it. I think that however we plan to achieve this should be part of the<br>
proposal.<br>
<br>
Albert<br>
<div><div class="h5"><br>
On Thu, Mar 5, 2015 at 1:19 AM, vineet garg <<a href="mailto:grgvineet@gmail.com">grgvineet@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> Here is the first implementation of sending payload using SSL on<br>
> github(<a href="https://github.com/grgvineet/kdeconnect-android/tree/ssl" target="_blank">https://github.com/grgvineet/kdeconnect-android/tree/ssl</a>).<br>
> It currently uses hard coded keystore which needs to saved on sdcad, but<br>
> working quite fine. Speed also quite fast and payload is fully encrypted,<br>
> tested with a text file and wireshark, no plaintext appeared.<br>
> This is just a test so may be code is little bit dirty :P<br>
><br>
><br>
> On Wed, Mar 4, 2015 at 11:30 PM, vineet garg <<a href="mailto:grgvineet@gmail.com">grgvineet@gmail.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> I want to work to improve KDEConnect encryption in this GSOC. I am<br>
>> thinking to implement following scheme:<br>
>> 1. Instead of using normal TCP we can use SSL/TLS to create session.<br>
>> 2. SSL/TLS, certificate for each device will be generated programmatically<br>
>> upon first use of application.<br>
>> 3. Instead of sharing public key on pairing, we can share certificates<br>
>> which will be stored on other device like we currently store public key.<br>
>> 4. Using a three way pairing so that user can verify other device's<br>
>> certificate by just verifying SHA fingerprint.<br>
>><br>
>> What we will be results :<br>
>> 1. Full packet encryption.<br>
>> 2. No need to encrypt manually, SSL will take care.<br>
>> 3. No replay attacks, due to nonces in SSL.<br>
>> 4. No man in the middle attack, because fingerprint will be changed if<br>
>> there is attack in pairing or certificates will not match if there is attack<br>
>> afterward.<br>
>> 5. Fast, as asymmetric cryptography only used for SSL handshake, after<br>
>> that symmetric cryptography will be used which is quite fast.<br>
>> 6. Payload encryption, as it is fast.<br>
>><br>
>> How I will do this:<br>
>> 1. Android supports SSL sockets and SSL server sockets throught<br>
>> Bouncycastle library.<br>
>> 2 We can generate certificate using Bouncycastle based on devices<br>
>> information programmatically.<br>
>> 3. Apache mina supports SSL filter over session.<br>
>> 4. QCA supports SSL/TLS.<br>
>> 5. We may implement openSSL (if possible, currently not sure).<br>
>><br>
>> I have already started working on it and look forward to further improve<br>
>> it and to discover vulnerabilities in this scheme.<br>
>><br>
>> Thanks<br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> KDEConnect mailing list<br>
> <a href="mailto:KDEConnect@kde.org">KDEConnect@kde.org</a><br>
> <a href="https://mail.kde.org/mailman/listinfo/kdeconnect" target="_blank">https://mail.kde.org/mailman/listinfo/kdeconnect</a><br>
><br>
</blockquote></div><br></div>