<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 17, 2015 at 12:33 PM, 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"><div dir="ltr"><div><span style="font-size:12.8000001907349px">Looks good. Some questions and comments:</span></div><div><br></div><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div></div><div>2. When RSA keys for the application are generated, a certificate for the user will also be generated which contains user data, fetched automatically from his system like user name, country etc. and certificate will be self signed with user's private key.</div></div></blockquote><div><br></div></span><div>Just a question to see if I understood this correctly: Is this private key you talk about something similar to the keys pairs that we currently exchange during the pairing? Are we also going to exchange these keys during the pairing with the new protocol?</div></div></div></div></blockquote><div><br></div><div>Yes, they are the same key pairs that we are currently using, certificate sharing is a sharing of public keys, but certificates are used each time to verify the peer during TLS handshake procedure to avoid any Man-in-the-Middle attack.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>4. TcpServerSocket needs to be replaced with WebServerSocket, both are nearly same but WebServerSocket provides functionality to integrate TLSv1.2.<br></div></div></blockquote><div><br></div></span><div>What's the difference between QWebSocket and QSslSocket and why did you choose WebSocket in this case?</div></div></div></div></blockquote><div><br></div><div>I wrote WebServerSocket which analogous to SslServerSocket, as there is no such class called SslServerSocket. QSslSocket is analogous to QTcpSocket, so QSslSocket will replace QTcpSocket and QWebSocketServer will replace QTcpServer.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>1. Android by default uses Bouncy Castle(BC) library and JAVA library for various encryption purposes, BC will be further explored to generate certificates with the key.</div></div></blockquote><div><br></div></span><div>Just another question to see if I understand: The new kind of sockets will do all the encryption/decryption, and BC and QCA are now going to be used only to generate the needed keys and certificates? </div></div></div></div></blockquote><div><br></div><div>Yes, BC and QCA are just used to generate keys and certificates, as native JAVA and Qt library doesn't support generation of certificate, but good part is they are already included in our project and we don't need to add something.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>4. This certificate will be used when applying TLS filter over session created by Apache Mina.<br></div></div></blockquote><div><br></div></span><div>Good call to use Mina so we get to reuse some stuff, and also shows you have documented about the current code works :)</div></div></div></div></blockquote><div><br></div><div>I spent quite some time to figure out to make minimal changes to apply this. :) <br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div></div><div>5. As pointed out by Albert, that KDE application upgrades are not as frequent as Android's, so a new LanLinkProvider (SslLanLinkProvider) will be used. So we will have two link providers in Android version of application.</div><div>6. Each link provider decide itself whether to create a link with other device based on its identity package which contains a field called isSslSupported.</div></div></blockquote><div><br></div></span><div>This does not scale very well when we add other protocol (eh: Bluetooth, direct USB connection, over the cloud...). I would try to simply instantiate always both protocols and one will fail to connect and the other will succeed, so we will use the one that succeded. If this doesn't work for some reason, maybe we can have an array like "supportedProtocols: ["ssl", "bluetooth"]", but anyway not a boolean per protocol.</div></div></div></div></blockquote><div><br></div><div>Yes, may be we could just use that in identity package that which Links the device support and choose the best amongst them. Like with order SSL, normal, bluetooth, wired<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>9. Since SslLanLink does encryption of data itself, so LanLink should also do it. So encryption of network package will be moved to LanLink from Network package so each link manages its own encryption scheme.</div></div></blockquote><div><br></div></span><div>Perfect, handling the encryption should be done inside the link, and not in higher level classes like Device as we do now. It would be nice to do this in the KDE side as well, even though we will only have one protocol for now.</div></div></div></div></blockquote><div><br></div><div>Alright, symmetry will make further development easy.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>The use of TLSv1.2 follows Public Key Infrastructure(PKI), where there are some trusted parties and they verifies the certificate,i.e. these trusted third parties sign the certificate with their own private key. User can authenticate certificates by using the public key of third party. Since we cannot use third parties here and we assume that user trusts himself most, so during pairing process hash of public key will be shown to user to verify it manually to avoid any Man-in-the-Middele(MitM) attack. Once the pairing process is done, other party's certificate will be saved and we will use that certificate for any future communication. This method ensure no MitM attack in the future.</div></div></blockquote><div><br></div></span><div>Showing a hash doesn't seem very user friendly. Maybe we can reduce that to a short pin (like the 4-digit numbers in bluetooth pairing).</div></div></div></div></blockquote><div><br></div><div>May be we could use just some initials of hash, as git does while showing history. I first thought of showing an Identicon , but later thought that It will go out of scope. Maybe in future we could do this.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>15 June – 21 June : Testing the application by running it on various devices(using different images in emulator)</div></div></blockquote><div><br></div></span><div>And fixing bugs :) You probably don't need to test it on many virtual devices, I have three phones I can use to test and you probably have one, so that should be enough. This way you can save time to use fixing bugs, because assume there will be bugs, and that they will take longer than expected to fix.</div><span class=""><div> </div></span></div></div></div></blockquote><div> </div><div>A wrong implementation sometimes leads to Handshake failure without showing cause, it is hard to debug it sometimes. Also I need to test a lot with using Wireshark using SSL private key to ensure the implementation is alright and all data is encrypted correctly.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>4 July – 10 July : Generating certificates for KDE version of KDE connect and saving it</div><div>along with the key in PEM format.</div></div></blockquote><div><br></div></span><div>One week seems a lot of time to do this. </div></div></div></div></blockquote><div><br></div><div>Ok, I will use this time to refactor code to abstract Link, and merge it with next week's work.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div></div><div>25 July – 31 July : Integrating both Android and KDE version with each other. Handling any problems caused due to difference in APIs and their implementation.</div></div></blockquote><div><br></div></span><div>One week seems quite short for this. You probably want to compact the previous tasks a bit so you have more time for this part.</div><div><br></div></div></div></div></blockquote><div><br></div><div>All though they are universally accepted, their should not be any problem in integrating it.  But I kept it for some safe side cause once they are working with same type of devices like Android version is working fine by itself and so do KDE version, they should automatically work fine with each other.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>That's all!<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>Albert<br></div><div><br></div></font></span></div></div></div>
</blockquote></div><br></div><div class="gmail_extra">Alright, so at the time where I was generating certificates in KDE version, which seems too short to you, I will refactor code for Link abstraction, and generate certificate and integrate with session on next week,<br></div><div class="gmail_extra">Instead of showing hash, some initials of hash will be shown for verification of the user.<br><br></div><div class="gmail_extra">Thanks<br></div></div>