Review Request 124312: Initial SSL implementation

Tue Jul 21 21:38:12 UTC 2015

> On July 21, 2015, 5:28 a.m., Albert Vaca Cintora wrote:
> > core/backends/lan/lanlinkprovider.cpp, line 287
> > <https://git.reviewboard.kde.org/r/124312/diff/3/?file=386052#file386052line287>
> >
> >     I though all our certificates were self-signed, how is this an error that causes us to unpair?

When we don't trust the other device, we use query peer to just ask for certificate, but when we trust it verify peer is used. Since we trust it we have its certificate which is added to socket's CA certificate list so that it can be authenticated. If some man in the middle sends another certificate, which is again self signed, the authenitication will fail automatically. Conditions here handle this type of situation. I tried to add here all cases which should not be trusted at all.

> On July 21, 2015, 5:28 a.m., Albert Vaca Cintora wrote:
> > core/backends/lan/server.h, line 28
> > <https://git.reviewboard.kde.org/r/124312/diff/3/?file=386055#file386055line28>
> >
> >     Can you add a comment explaining why did you have to extend QTcpServer? ie: why was not enough to just use it directly.

On using QTcpServer directly it binds QTcpSocket to native socket descriptor, setting SSL configuration to it is not possible. By using custom server QSslSocket is binded to native socket descriptor and QSslSocket is returned by nextPendingConnection instead of QTcpSocket.

> On July 21, 2015, 5:28 a.m., Albert Vaca Cintora wrote:
> > core/backends/lan/downloadjob.cpp, line 29
> > <https://git.reviewboard.kde.org/r/124312/diff/3/?file=386048#file386048line29>
> >
> >     I thought we were not keeping backwards compatibility with non-ssl kdeconnects on the KDE side. What's the purpose fo all this "useSsl" thingy?

I thought It would be good here since people use it to connect pc's and laptops also for file sharing. Although it can be removed easily.

> On July 21, 2015, 5:28 a.m., Albert Vaca Cintora wrote:
> > cli/kdeconnect-cli.cpp, line 151
> > <https://git.reviewboard.kde.org/r/124312/diff/3/?file=386044#file386044line151>
> >
> >     Use spaces instead of tabs.

Ok

> On July 21, 2015, 5:28 a.m., Albert Vaca Cintora wrote:
> > core/device.cpp, lines 212-213
> > <https://git.reviewboard.kde.org/r/124312/diff/3/?file=386067#file386067line212>
> >
> >     This long chain of -> looks bad. Change this to be a Q_FOREACH(PairingHandler handler, pairingHandlers). You should have a way to get all the pairing handlers to do that. Now, you are only going through the pairing handlers of the providers which can currently see the device, instead of all.

I told you earlier that there can be two approaches, pair one time and use a some kind of meta pairing package with all info. This is where we need all pairing handlers at one. In current approach device will be paired using the availaible link. Later if some some other links tries to connect and find out that the device is paired but needed data is not their, it will send pairing request automatically. Like if device is paired and certificate or public key is not there it will send a pairing request automatically. Since it is paired from other side too, other side will respond automatically. The automatic response is already added but and an automatic pairing request is not yet added here, but added on Android side.

> On July 21, 2015, 5:28 a.m., Albert Vaca Cintora wrote:
> > core/device.cpp, lines 284-286
> > <https://git.reviewboard.kde.org/r/124312/diff/3/?file=386067#file386067line284>
> >
> >     Should be done in the pairing handler.

But it's not related to pairing. It is how I set the certificate by adding it to identity package after handshake.

> On July 21, 2015, 5:28 a.m., Albert Vaca Cintora wrote:
> > core/device.cpp, line 474
> > <https://git.reviewboard.kde.org/r/124312/diff/3/?file=386067#file386067line474>
> >
> >     Split into storeDevicPublicKey and storeDeviceCertificate. PS: Actually I see that you already started doing that with setDeviceProperty and getDeviceProperty, even though you never used it. That seems a better approach than this.

What about adding a generalised addTrustedDevice funtion with a QMap as input ?

- Vineet

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124312/#review82739
-----------------------------------------------------------

On July 19, 2015, 4:33 p.m., Vineet Garg wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124312/
> -----------------------------------------------------------
> 
> (Updated July 19, 2015, 4:33 p.m.)
> 
> 
> Review request for kdeconnect.
> 
> 
> Repository: kdeconnect-kde
> 
> 
> Description
> -------
> 
> * Similar to Android version, this SSL implementation supports old version also.
> * Certificate is generated when public key is generated using QCA, but used as QSslCertificate because QSslSocket don't like QCA certificate.
> * A new server is written overriding QTcpServer for setting socket descriptor to QSslSocket.
> * QSslSocket works as plain socket to transfer identity package and then either uses encrypted mode or normal mode according to the received package.
> * If connetion is to be on SSL, new link is only added after successful handshake.
> * Certificate is embedded into identity package on start of encrypted mode and then set in device using it.
> * PairingHandler is added like in Android version so that each LinkProvider manage pairing according to its own rules.
> 
> P.S. : Uploaded the patch with some debug statements, will comment out them.
> 
> 
> Diffs
> -----
> 
>   cli/kdeconnect-cli.cpp 3aa49e5 
>   core/CMakeLists.txt dd8fedb 
>   core/backends/lan/CMakeLists.txt 7c5be38 
>   core/backends/lan/downloadjob.h eeeab07 
>   core/backends/lan/downloadjob.cpp bba2e98 
>   core/backends/lan/landevicelink.h 7d31881 
>   core/backends/lan/landevicelink.cpp 0987057 
>   core/backends/lan/lanlinkprovider.h b379434 
>   core/backends/lan/lanlinkprovider.cpp f5d2b22 
>   core/backends/lan/lanpairinghandler.h PRE-CREATION 
>   core/backends/lan/lanpairinghandler.cpp PRE-CREATION 
>   core/backends/lan/server.h PRE-CREATION 
>   core/backends/lan/server.cpp PRE-CREATION 
>   core/backends/lan/socketlinereader.h b3be55a 
>   core/backends/lan/socketlinereader.cpp a6bd85e 
>   core/backends/lan/uploadjob.h 12b6f7e 
>   core/backends/lan/uploadjob.cpp b0d35fc 
>   core/backends/linkprovider.h f4fc309 
>   core/backends/pairinghandler.h PRE-CREATION 
>   core/backends/pairinghandler.cpp PRE-CREATION 
>   core/daemon.h 674ca01 
>   core/daemon.cpp af4c67b 
>   core/device.h 03f528c 
>   core/device.cpp c2dc609 
>   core/kdeconnectconfig.h af6c6df 
>   core/kdeconnectconfig.cpp 919505c 
>   core/networkpackage.h 6a0bf9c 
>   core/networkpackage.cpp 64cfab7 
>   tests/CMakeLists.txt b00a574 
>   tests/testsocketlinereader.cpp 77a9b4b 
> 
> Diff: https://git.reviewboard.kde.org/r/124312/diff/
> 
> 
> Testing
> -------
> 
> * Working fine, tested using connection to Android devices.
> * Pairing handler needs to be tested using two LinkProvider, working fine with one, but there be some problems with two LinkProviders simultaneouly.
> 
> 
> Thanks,
> 
> Vineet Garg
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20150721/1a2fe122/attachment-0001.html>