| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
3.9 On Record Padding
The TLS protocol allows for random padding of records, to make it more difficult to perform analysis on the length of exchanged messages. (In RFC 4346 this is specified in section 6.2.3.2.) GnuTLS appears to be one of few implementation that take advantage of this text, and pad records by a random length.
The TLS implementation in the Symbian operating system, frequently
used by Nokia and Sony-Ericsson mobile phones, cannot handle
non-minimal record padding. What happens when one of these clients
handshake with a GnuTLS server is that the client will fail to compute
the correct MAC for the record. The client sends a TLS alert
(bad_record_mac) and disconnects. Typically this will result
in error messages such as ’A TLS fatal alert has been received’, ’Bad
record MAC’, or both, on the GnuTLS server side.
GnuTLS implements a work around for this problem. However, it has to
be enabled specifically. It can be enabled by using
gnutls_record_disable_padding, or gnutls_priority_set with
the %COMPAT priority string.
If you implement an application that have a configuration file, we recommend that you make it possible for users or administrators to specify a GnuTLS protocol priority string, which is used by your application via gnutls_priority_set. To allow the best flexibility, make it possible to have a different priority string for different incoming IP addresses.
To enable the workaround in the gnutls-cli client or the
gnutls-serv server, for testing of other implementations, use
the following parameter: --priority "%COMPAT".
This problem has been discussed on mailing lists and in bug reports. This section tries to collect all pieces of information that we know about the problem. If you wish to go back to the old discussions, here are some links:
http://thread.gmane.org/gmane.ietf.tls/3079
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |