Qt-interest Archive, April 2008
ssh tunnel
Message 1 in thread
Hi,
any clues or hints for an ssh tunnel library? preferable with a Qtish API.
commercial or open source.
So far libssh2 failed and libssh isn't cross platform.
Or maybe any ideas for both encryption and key based authentification.
QSslSocket didn't turn out to work becouse client auth can't be verified
properly.
thanks.
--
[ signature omitted ]
Message 2 in thread
Quoting Arvid Ephraim Picciani <aep@xxxxxxxxxxxxxxx>:
> Hi,
> any clues or hints for an ssh tunnel library? preferable with a Qtish API.
> commercial or open source.
> So far libssh2 failed and libssh isn't cross platform.
>
> Or maybe any ideas for both encryption and key based authentification.
> QSslSocket didn't turn out to work becouse client auth can't be verified
> properly.
What about this one? Dual licensed under QPL and commercial:
http://netsieben.com/products/ssh/
--
[ signature omitted ]
Message 3 in thread
On Monday 28 April 2008 22:34:54 Pau Garcia i Quiles wrote:
> What about this one? Dual licensed under QPL and commercial:
> http://netsieben.com/products/ssh/
looks very nice.
was a hell to compile and the example just times out :(
but i'll play around a bit with it. thanks alot!
--
[ signature omitted ]
Message 4 in thread
On 28-Apr-08, at 2:21 PM, Arvid Ephraim Picciani wrote:
> Hi,
> any clues or hints for an ssh tunnel library? preferable with a
> Qtish API.
> commercial or open source.
> So far libssh2 failed and libssh isn't cross platform.
>
> Or maybe any ideas for both encryption and key based authentification.
> QSslSocket didn't turn out to work becouse client auth can't be
> verified
> properly.
What are you trying to do exactly? The SRP protocol is a good method
to setup encryption and uses a password for authentication. This may
sound insecure but its actually very strong and quite useful as an
alternative to SSL if you don't want to use a trusted third-party. I
have a Qt implementation that I need to cleanup and can then release
in the public domain.
A note on this is that its a shame that Trolltech didn't go more
general in their encryption API. Its really only any good for SSL/TLS
while it would have been useful to have more direct access to
encryption and hashing. Something where you could do SHA-1,
SHA-256, ... hashing and the ability to setup encryption using
Blowfish, Two-fish, AES, ... If you are already wrapping the openssl
library to get the SSL/TLS stuff, the rest of this could be wrapped
too! Wouldn't mind a Bignum wrapper as well!
--
[ signature omitted ]
Message 5 in thread
> What are you trying to do exactly?
tunnel a nodetalk/carrier (database) connection over a secure channel and
additonaly have a strong authentification with large keys.
i guess long passwords work as well, as long as they are protected in a way
like ssh.
> The SRP protocol is a good method
> to setup encryption and uses a password for authentication.
isn't SRP pre stonage?
need to read some docs about it...
> This may
> sound insecure but its actually very strong and quite useful as an
> alternative to SSL if you don't want to use a trusted third-party. I
> have a Qt implementation that I need to cleanup and can then release
> in the public domain.
hmm sounds interesting! I'd love to try it. If it's self containing it might
be even go into libqxt (QxtCrypto) if you allow.
> A note on this is that its a shame that Trolltech didn't go more
> general in their encryption API. Its really only any good for SSL/TLS
yes
> while it would have been useful to have more direct access to
> encryption and hashing.
yes :(
well i'm quiet happy we at least got SSl.
--
[ signature omitted ]
Message 6 in thread
On 28-Apr-08, at 3:26 PM, Arvid Ephraim Picciani wrote:
>
>> What are you trying to do exactly?
>
> tunnel a nodetalk/carrier (database) connection over a secure
> channel and
> additonaly have a strong authentification with large keys.
> i guess long passwords work as well, as long as they are protected
> in a way
> like ssh.
The nice thing about SRP is that you are not depending on the password
length for security so it doesn't need to be long. And its not
transfered in any way from the client to the server so its safe that
way as well. And the end result is that you get a large private key
that can be used between the client and server for encryption.
>
>> The SRP protocol is a good method
>> to setup encryption and uses a password for authentication.
>
> isn't SRP pre stonage?
> need to read some docs about it...
Perhaps you are thinking of some other thing with the same letters?
The first RFC for it, number 2945, is from 2000. Wikipedia has a good
article on it.
>
>> This may
>> sound insecure but its actually very strong and quite useful as an
>> alternative to SSL if you don't want to use a trusted third-party. I
>> have a Qt implementation that I need to cleanup and can then release
>> in the public domain.
>
> hmm sounds interesting! I'd love to try it. If it's self containing
> it might
> be even go into libqxt (QxtCrypto) if you allow.
Sure. I'll try to wrap it all up. It depends on having the following
though:
1. Big integer support. I'm using BIGNUM from openssl but considering
switching to a more openly licensed library or making it configurable
so that the implementation is hidden and then support openssl,
libtommath, and others.
2. Hashing. Ideally I'd like to have some of the big hashes like
SHA-256 or SHA-512. Again I'm using openssl right now for this but
would like to make it configurable.
3. Crypto grade random number generation. Yet again using openssl.
The trickiest part of this is to have a decent initial entropy supply
that is cross-platform but it looks like Linux and Mac has /dev/
urandom and on Windows you can use its crypto libraries.
With those three things you can write an SRP implementation. Of
course in the end what you get is the assurance that the client side
knows the proper password for the username being used and you get a
large private key you can then use with some symmetric encryption
method like Blowfish, Two Fish, AES, ...
>
>> A note on this is that its a shame that Trolltech didn't go more
>> general in their encryption API. Its really only any good for SSL/
>> TLS
> yes
>> while it would have been useful to have more direct access to
>> encryption and hashing.
> yes :(
> well i'm quiet happy we at least got SSl.
Yes that is true. Just a part of the security picture though!
--
[ signature omitted ]
Message 7 in thread
Consider a class subclassed from QSslSocket and hitting an HTTPS
server. (I can't use the HTTP class because I need to setup custom
headers.)
My class is pointer based, i.e. it is dynamically allocated using
new. I am able to connect and read my data. The problem I was seeing
is that even though I have received all the data, the remote server is
not closing the connection. So, when I see that I have content equal
to Content-Length, I give a disconnect to the class. I'm having a
problem because I am not certain when it is safe to delete the
instance of my socket class. I delete when I think it is safe but at
a later point, an event occurs and the code tries to do something with
the class. Is there something I need to do so that the remote will
disconnect, thereby causing the disconnect signal to fire? Or is
there some signal that I can key off of that will let me know that the
class can be deleted.
I have tried so many permutations and at this point, I would welcome
any help.
Thanks,
Michael
--
[ signature omitted ]
