[Help-gnutls] Re: getting gnutls-serv to work with SRP

[Simon Josefsson]

"Avasarala Ranjit-A20990" <ranjit at motorola.com> writes:

>  
> Hi Simon
>
> I got the gnutls-cli-debug and gnutls-serv worked with x509. Now I am
> facing a problem with SRP
>
> Server
>
> src/gnutls-serv --srppasswd ./tpasswd.conf
> Error while setting SRP parameters
> Error: The request is invalid.
> Echo Server ready. Listening to port '5556'.
>
> Exiting via signal 2

Is your tpasswd.conf valid?  You have to generate it using srptool.

For example:

jas at mocca:~/src/gnutls/src$ ./srptool --create-conf tpasswd.conf
...
jas at mocca:~/src/gnutls/src$ ./srptool -u jas -p tpasswd -c tpasswd.conf
Enter password: [I type 'FOO' here]
jas at mocca:~/src/gnutls/src$ ./gnutls-serv --srppasswd ./tpasswd --srppasswdconf ./tpasswd.conf
Echo Server ready. Listening to port '5556'.

Then start a client as:

jas at mocca:~/src/gnutls/src$ ./gnutls-cli --srpusername jas --srppasswd foo localhost --port 5556

The gnutls-serv process will then print:

* connection from ::ffff:127.0.0.1, port 55729
- SRP authentication. Connected as 'jas'
- Version: TLS 1.1
- Key Exchange: SRP
- Cipher: AES 128 CBC
- MAC: SHA
- Compression: DEFLATE

/Simon

>
>
> Regards
> Ranjit
>
> -----Original Message-----
> From: Simon Josefsson [mailto:simon at josefsson.org] 
> Sent: Wednesday, December 06, 2006 11:24 PM
> To: Avasarala Ranjit-A20990; Saha Diptikalyan-brp387
> Subject: Re: getting gnutls-serv to work
>
> Hi again.  Version 1.6.0 is the latest and most stable release.
> Version 1.7.0 is based on 1.6.0, but it is the experimental branch
> (1.7.x), and is thus less stable and not recommended for stable work,
> but it supports TLS 1.2 as well.
>
> I found your problem.  You need to start gnutls-serv with '-g' for it to
> generate Diffie-Hellman parameters.  That will slow things down, since
> it will generate DH params every time.  To speed things up, generate the
> parameters once, as follows:
>
> $ certtool --generate-dh-params > dh.pem ...
> $ gnutls-serv --dhparams dh.pem
>
> The second problem is a bug in gnutls-cli-debug.  A workaround is to
> start gnutls-serv with a X.509 key+cert.  E.g.:
>
> $ gnutls-serv --dhparams dh.pem --x509keyfile ~/self/certs/jas.key
> --x509certfile ~/self/certs/jas.cert
>
> Then gnutls-cli-debug will successfully establish connections using RSA
> key exchange.
>
> I'll work on having gnutls-cli-debug support anonymous connections when
> I get back from vacation in January.
>
> Regards,
> Simon
>
> "Avasarala Ranjit-A20990" <ranjit at motorola.com> writes:
>
>> Hi Simon
>>
>> Can u tell me which version of gnutls works fine, I mean which is the 
>> working version?
>>
>> Thanks in advance
>>
>>
>> Regards
>> Ranjit
>>
>> -----Original Message-----
>> From: Simon Josefsson [mailto:simon at josefsson.org]
>> Sent: Tuesday, December 05, 2006 8:19 PM
>> To: Avasarala Ranjit-A20990
>> Cc: Saha Diptikalyan-brp387
>> Subject: Re: getting gnutls-serv to work
>>
>> "Avasarala Ranjit-A20990" <ranjit at motorola.com> writes:
>>
>>> Hi Simon
>>>
>>> I am trying to use gnutls for my work. I am trying to run 
>>> gnutls-cli-debug/gnutls-cli and trying to connect to gnutls-serv. But
>
>>> I am getting following errors:
>>>
>>> I am using gnutls-1.7.0 for my work. 
>>>
>>> src/gnutls-serv --protocols TLS1.0
>>> socket() failed: Address family not supported by protocol Echo Server
>
>>> ready. Listening to port '5556
>>>
>>> ./gnutls-cli-debug localhost -p 5556
>>> Resolving 'localhost'...
>>> Connecting to '127.0.0.1:5556'...
>>> Checking for TLS 1.1 support... no
>>> Checking fallback from TLS 1.1 to... failed Checking for TLS 1.0 
>>> support... no Checking for SSL 3.0 support... no
>>>
>>> Server does not support none of SSL 3.0, TLS 1.0 and TLS 1.1
>>>
>>> How do I proceed further?
>>
>> Hi!  There is something wrong in the command line tools that leads to 
>> this, this was reported recently.  The library certainly support
>> SSL/TLS1.0/TLS1.1 (and as of 1.7.0, also TLS 1.2).  I'm not sure if 
>> the problem is in the server or client tool, maybe you could try 
>> replacing either one with a known-working peer and see what happens.
>> I suggest you try the examples instead, if your goal is to write your 
>> own code that uses the library.
>>
>> Unfortunately, I'm going on vacation next Monday, so I won't have time
>
>> to fix this until next year. :( I suspect it is something simple that 
>> have broken the command line tool.
>>
>> /Simon