diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/cha-programs.texi | 20 | ||||
| -rw-r--r-- | doc/cha-support.texi | 7 | ||||
| -rw-r--r-- | doc/cha-tls-app.texi | 12 |
3 files changed, 19 insertions, 20 deletions
diff --git a/doc/cha-programs.texi b/doc/cha-programs.texi index 46dfe107be..b0d46cf76c 100644 --- a/doc/cha-programs.texi +++ b/doc/cha-programs.texi @@ -411,15 +411,6 @@ Usage: gnutls-cli [options] hostname -v, --version prints the program's version number @end example -To connect to a server using PSK authentication, you may use something -like: - -@smallexample -$ gnutls-cli -p 5556 test.gnutls.org --pskusername jas \ - --pskkey 9e32cf7786321a828ef7668f09fb35db \ - --priority NORMAL:-KX-ALL:+ECDHE-PSK:DHE-PSK:+PSK -@end smallexample - @menu * Example client PSK connection:: @end menu @@ -428,6 +419,15 @@ $ gnutls-cli -p 5556 test.gnutls.org --pskusername jas \ @subsection Example client PSK connection @cindex PSK client +To connect to a server using PSK authentication, you may use something +like: + +@smallexample +$ gnutls-cli -p 5556 test.gnutls.org --pskusername jas \ + --pskkey 9e32cf7786321a828ef7668f09fb35db \ + --priority NORMAL:-KX-ALL:+ECDHE-PSK:+DHE-PSK:+PSK +@end smallexample + If your server only supports the PSK ciphersuite, connecting to it should be as simple as connecting to the server: @@ -482,7 +482,7 @@ This program was created to assist in debugging @acronym{GnuTLS}, but it might be useful to extract a @acronym{TLS} server's capabilities. It's purpose is to connect onto a @acronym{TLS} server, perform some tests and print the server's capabilities. If called with the `-v' -parameter a more checks will be performed. An example output is: +parameter more checks will be performed. An example output is: @example crystal:/cvs/gnutls/src$ ./gnutls-cli-debug localhost -p 5556 diff --git a/doc/cha-support.texi b/doc/cha-support.texi index 604f85fce5..835482feca 100644 --- a/doc/cha-support.texi +++ b/doc/cha-support.texi @@ -56,7 +56,7 @@ E-mail: simon@josefsson.org @end verbatim If your company provides support related to GnuTLS and would like to -be mentioned here, contact the authors using the address at @ref{Bug Reports}. +be mentioned here, contact the authors. @node Downloading and Installing @section Downloading and Installing @@ -155,7 +155,7 @@ Send your bug report to: @cindex Contributing @cindex Hacking -If you want to submit a patch for inclusion -- from solve a typo you +If you want to submit a patch for inclusion -- from solving a typo you discovered, up to adding support for a new feature -- you should submit it as a bug report, using the process in @ref{Bug Reports}. There are some things that you can do to increase the chances for it to be included @@ -168,8 +168,7 @@ already signed papers, we will send you the necessary information when you submit your contribution. For contributions that doesn't consist of actual programming code, the -only guidelines are common sense. Use it. - +only guidelines are common sense. For code contributions, a number of style guides will help you: @itemize @bullet diff --git a/doc/cha-tls-app.texi b/doc/cha-tls-app.texi index 93445227b2..b8e83ed2a8 100644 --- a/doc/cha-tls-app.texi +++ b/doc/cha-tls-app.texi @@ -43,12 +43,13 @@ soon obsoleted. Other application protocols@footnote{See LDAP, IMAP etc.} use a different approach to enable the secure layer. They use something -called the ``TLS upgrade'' method. This method is quite tricky but it +often called as the ``TLS upgrade'' method. This method is quite tricky but it is more flexible. The idea is to extend the application protocol to have a ``STARTTLS'' request, whose purpose it to start the TLS protocols just after the client requests it. This approach -does not require an extra port and is used by almost all modern protocols. -There is even an extension to HTTP protocol to support that method @xcite{RFC2817}. +does not require any extra port to be reserved. +There is even an extension to HTTP protocol to support +that method @xcite{RFC2817}. The tricky part, in this method, is that the ``STARTTLS'' request is sent in the clear, thus is vulnerable to modifications. A typical @@ -94,7 +95,7 @@ CLIENT: HERE ARE SOME CONFIDENTIAL DATA As you can see above the client was fooled, and was dummy enough to send the confidential data in the clear. -How to avoid the above attack? As you may have already thought this +How to avoid the above attack? As you may have already noticed this one is easy to avoid. The client has to ask the user before it connects whether the user requests @acronym{TLS} or not. If the user answered that he certainly wants the secure layer the last @@ -123,5 +124,4 @@ traditional method, and the security properties remain the same, since only denial of service is possible. The benefit is that the server may request additional data before the @acronym{TLS} Handshake protocol starts, in order to send the correct certificate, use the correct -password file@footnote{in @acronym{SRP} authentication}, or anything -else! +password file, or anything else! |