Another one of those beloved tls-bugs. I recently got myself a
SonyEricsson P990 smart phone. When trying to send mail with tls (the
same happens using ssl on port 465), the phone asks me to accept the
certificate, and then says "Secure session failed". I get this in my
Exim log:

2006-10-02 18:49:23 SMTP connection from [192.168.1.8]:59691 I=[193.91.240.190]:25 (TCP/IP connection
count = 1)
2006-10-02 18:49:23 no host name found for IP address 192.168.1.8
2006-10-02 18:49:27 TLS recv error on connection from [192.168.1.8]:59691: A TLS fatal alert has been
received.: Bad record MAC
18:49:27 TLS send error on connection from [192.168.1.8]:59691: The specified session has been
invalidated for some reason.

TLS works fine with Thundebird and Evolution, and did work fine with
my previous smart phone (SE P910), so this may sound like a phone bug.
_But_ when I try to send with tls through a sendmail server, it works
fine. I suspect that this is due to the fact that sendmail uses
openssl, and exim gnutls, but I have no evidence of that.

The error message isn't very helpful neither ("for some reason").

Any insight?

Best regards,
Stian

tags #390712 help
user exim4@packages.debian.org
usertags #390712 gnutls
thanks

unfortunately, no. We're still in dire need of help with GnuTLS.

Greetings
Marc

tags #390712 help
user exim4@packages.debian.org
usertags #390712 gnutls
thanks

unfortunately, no. We're still in dire need of help with GnuTLS.

Greetings
Marc

Hi, same happens with Nokia E60 phone. All other SSL/TLS (imaps, https) Services work
fine when accessed from the phone, only exim fails when trying to send messages.

Hi,

I have an issue with exim4 that can, IMO, clearly be traced to GnuTLS.
Please refer to #390712 for more information.

The original reporter, Stian Jordet <stian@jordet.net>, has a
SonyEricsson P990, and Marc Fargas <telenieko@telenieko.com> reports
the same issue with a Nokia E60 (Software Version 2.0618.06.05
(RM-49)).

I did some testing with Marc, and his phone was perfectly able to do
STARTTLS with an exim compiled against OpenSSL. Both exims were build
on the same Debian unstable system by myself, so I am reasonably sure
that we have a GnuTLS issue here.

Marc is willing to debug with him, and I can also put you in contact
with a close friend of mine who is plagued with the same issue with
his new mobile phone against his exim installation.

If there is anything that I can do to help, please get in touch with
me, and by all means keep me posted.

I am subscribed to pkg-gnutls-maint.

Greetings
Marc

Hi,

I also have a Sony-Ericsson P990i (Germany, non-branded by a phone
provider)

My software versions on the mobile phone are:

PDA Software Version:
CXC162036 R3A04
Phone-Software-Version:
CXC152037 R5A006
Bluetooth Software Version:
CXC162058 R4F01
CDA-Version:
CDA162007/3 R3A03

I have the same problem with Exim - I try to do an smtp auth via
TLS, I get the certificate on the phone and accept to use it, but
then it just doesn't work. On the Exim-Side I only see the following:

2006-12-04 15:01:22 no host name found for IP address 82.113.121.1
2006-12-04 15:01:51 TLS recv error on connection from [82.113.121.1]: A TLS fatal alert has been received.: Bad record MAC
2006-12-04 15:01:51 TLS send error on connection from [82.113.121.1]: The specified session has been invalidated for some reason.

2006-12-04 15:02:44 no host name found for IP address 82.113.106.1
2006-12-04 15:02:51 TLS recv error on connection from [82.113.106.1]: A TLS fatal alert has been received.: Bad record MAC
2006-12-04 15:02:51 TLS send error on connection from [82.113.106.1]: The specified session has been invalidated for some reason.

2006-12-04 16:20:03 no host name found for IP address 82.113.106.1
2006-12-04 16:20:15 TLS recv error on connection from [82.113.106.1]: A TLS fatal alert has been received.: Bad record MAC
2006-12-04 16:20:15 TLS send error on connection from [82.113.106.1]: The specified session has been invalidated for some reason.

Without TLS it works:

2006-12-04 16:23:09 no host name found for IP address 82.113.106.1
2006-12-04 16:23:20 1GrFf4-00085h-Cv <= user@invalid H=([10.68.232.75]) [82.113.106.1] P=esmtpa A=login_server:user@invalid S=563 id=XSbjPMP4Wh8j.hG8LVVBK@invalid

(mail addresses taken out)

Ciao, Hanno

clone #390712 -1
reassign -1 libgnutls13
retitle -1 errors establishing TLS session from Nokia and SE mobile phones
submitter -1 mh+debian-packages@zugschlus.de
block #390712 with -1
thanks

According to the discussion in
http://lists.alioth.debian.org/pipermail/pkg-gnutls-maint/2006-December/000349.html
and previous articles, it has been established that this is a gnutls
issue. I am therefore cloning the bug to libgnutls13.

Greetings
Marc

Ok it seems that with the help of Hanno Wagner I managed to debug this issue.
These clients fail to understand TLS 1.0 record packets with a padding added.
This only occurs when using non stream ciphers (i.e. not arcfour) and does
not occur when using SSL 3.0 which does not allow such padding. So one point
is for users of these devices to report that as bug.

However a fix in gnutls is not easy to do. If we disable the random padding in
TLS 1.0 we do disable a nice feature of TLS that protects against statistical
attacks. Thus I'd be against such a fix.

A solution for the clients would be to only allow SSL 3.0 (if they can
configure it).

What I can do within gnutls is to add a function to disable this protection
and servers that require maximum compatibility could use it.

(thus gnutls 2.2 will introduce gnutls_session_enable_compatibility_mode() to
counter client bugs)

regards,
Nikos

I believe we have identified that the problem in this bug is the MAC
padding.  We brought this up on the IETF TLS list:

http://thread.gmane.org/gmane.ietf.tls/3079

Pasi forwarded this to the Symbian TLS team, and my understanding is
that it is a known bug with the Symbian TLS implementation.

GnuTLS won't change the default to cater with broken implementations, at
least not without more justification that it is a widespread problem.  I
think this bug can be resolved as 'wontfix'.

Further, GnuTLS 2.2+ provides a mechanism to work around bugs in
implementations.  You should be able to connect the Nokia E90 to
gnutls-serv if you start it as:

$ gnutls-serv --priority "NORMAL:%COMPAT"

Applications can use the following functions to implement similar
behaviour:

  int gnutls_priority_init( gnutls_priority_t*, const char *priority, const char** err_pos);
  void gnutls_priority_deinit( gnutls_priority_t);

  int gnutls_priority_set(gnutls_session_t session, gnutls_priority_t);
  int gnutls_priority_set_direct(gnutls_session_t session, const char *priority, const char** err_pos);

I recommend that applications offer a way to set the GnuTLS priority
string in a configuration file, and to default it to 'NORMAL'.  It is
extra good if the application allows users to set the GnuTLS priority on
a per-IP basis, so that administrators doesn't have to decrease security
to cater for a few broken devices.

Given this, I think gnutls has done what it can about this bug, and it
might be appropriate to even close it, rather than leaving it in
wontfix.

Is there anything more we can do about this bug?  Suggestions are most
welcome.

/Simon

At least we know who's at fault here.

I agree.

Since mobile phones usually connect with a dynamic IP address, this
will most probably end up with a 0.0.0.0/0.0.0.0 netmask though.

I'd love to have some permanent reference that can be found by Symbian
device owners and referenced in response to new bug reports.

Greetings
Marc

Marc Haber <mh+debian-packages@zugschlus.de> writes:

True..  however some may know which IP addresses are affected, so making
this possible would be useful.  At least I could list the networks of my
3G provider.

Good idea.  I'm trying to find a good place in the manual to discuss
'MAC padding' and its interop problems.

/Simon

Simon Josefsson <simon@josefsson.org> writes:

Added:

http://www.gnu.org/software/gnutls/manual/html_node/On-Record-Padding.html

/Simon

El lun, 04-02-2008 a las 14:12 +0100, Marc Haber escribió:

Here's a E60 and N95 owner (and a [currently] broken E61 too) glad to
tests things ;)

The easiest to play with is the N95 as it's my phone but can try stuff
in the E60 also without problem.

So just ask for anything you want me to try ;)

Cheers,
Marc

tag 402861 wontfix
thanks

I'm tagging this bug as wontfix because I don't see us doing much more
about it.  The problem appears to be well understood now.  We decided
not to change the implementation's default behaviour.  We offer
workarounds for the bug for applications, and the problem and
workarounds are discussed in the GnuTLS manual [1].

If there is anything more we could do here, feel free to raise it in
this bug.  (I'm assuming wontfix bugs aren't archived?)

Thanks,
/Simon

[1] http://www.gnu.org/software/gnutls/manual/html_node/On-Record-Padding.html

I have forwarded the issue to exim upstream in February. They'd love
to see some code illustrating what to do.

Is there anybody willing to help?

The upstream bugzilla can be found here
http://bugs.exim.org/show_bug.cgi?id=665

Greetings
Marc

Dear Customer,

We can not deliver your parcel arrived at March 07.

Please review delivery label in attachment!

Thanks and best regards,
Francis Whitney,
UPS Chief Support Manager.

I=[193.91.240.190]:25 (TCP/IP connection
[192.168.1.8]:59691: A TLS fatal alert has been
specified session has been
Content_Scanning Old_Demime
dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql
redirect
MTA (v4
libraries
Libraries [
runtime libr