Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.security > #4676 > unrolled thread

SSL/TLS still seems to be screwed up (retrieving Mail with Thunderbird)

Started byElmar Stellnberger <estellnb@gmail.com>
First post2016-04-10 18:30 +0200
Last post2016-04-11 22:50 +0200
Articles 13 — 5 participants

Back to article view | Back to linux.debian.security


Contents

  SSL/TLS still seems to be screwed up (retrieving Mail with  Thunderbird) Elmar Stellnberger <estellnb@gmail.com> - 2016-04-10 18:30 +0200
    Re: SSL/TLS still seems to be screwed up (retrieving Mail with Thunderbird) Brandon Vincent <Brandon.Vincent@asu.edu> - 2016-04-11 00:10 +0200
      Re: SSL/TLS still seems to be screwed up (retrieving Mail with  Thunderbird) Elmar Stellnberger <estellnb@gmail.com> - 2016-04-11 08:30 +0200
    Re: SSL/TLS still seems to be screwed up (retrieving Mail with  Thunderbird) Evgeny Kapun <abacabadabacaba@gmail.com> - 2016-04-11 09:00 +0200
      Re: SSL/TLS still seems to be screwed up (retrieving Mail with  Thunderbird) Elmar Stellnberger <estellnb@gmail.com> - 2016-04-11 10:20 +0200
        Re: SSL/TLS still seems to be screwed up (retrieving Mail with Thunderbird) Vladislav Kurz <vladislav.kurz@webstep.net> - 2016-04-11 11:30 +0200
          Re: SSL/TLS still seems to be screwed up (retrieving Mail with  Thunderbird) Elmar Stellnberger <estellnb@gmail.com> - 2016-04-11 19:30 +0200
            Re: SSL/TLS still seems to be screwed up (retrieving Mail with Thunderbird) Vaughn Graham <vaughng@dmsllconline.net> - 2016-04-11 21:00 +0200
              Re: SSL/TLS still seems to be screwed up (retrieving Mail with  Thunderbird) Elmar Stellnberger <estellnb@gmail.com> - 2016-04-11 21:20 +0200
              Re: SSL/TLS still seems to be screwed up (retrieving Mail with Thunderbird) Brandon Vincent <Brandon.Vincent@asu.edu> - 2016-04-12 05:20 +0200
        Re: SSL/TLS still seems to be screwed up (retrieving Mail with Thunderbird) Brandon Vincent <Brandon.Vincent@asu.edu> - 2016-04-11 15:00 +0200
          Re: SSL/TLS still seems to be screwed up (retrieving Mail with  Thunderbird) Elmar Stellnberger <estellnb@gmail.com> - 2016-04-11 21:50 +0200
            Re: SSL/TLS still seems to be screwed up (retrieving Mail with  Thunderbird) Elmar Stellnberger <estellnb@gmail.com> - 2016-04-11 22:50 +0200

#4676 — SSL/TLS still seems to be screwed up (retrieving Mail with Thunderbird)

FromElmar Stellnberger <estellnb@gmail.com>
Date2016-04-10 18:30 +0200
SubjectSSL/TLS still seems to be screwed up (retrieving Mail with Thunderbird)
Message-ID<rmqpk-7ON-1@gated-at.bofh.it>
Dear Readers of Debian-Security,

   While being connected via an insecure VPN I had once more left my 
email client open by accident (Thunderbird). Though access to 
imap.gmail.com shall be secured by SSL/TLS my gmail password was 
malversated within a few seconds; i.e. I got a login attempt from 
HongKong and had to change the password after disconnecting.
   Is anyone here who can explain the insecurity of SSL/TLS in its 
current state? Does Thunderbird support certificate pinning? Or do you 
think that there are still errors in the implementation of the protocol? 
What about libressl for Linux?

Yours,
Elmar

[toc] | [next] | [standalone]


#4677 — Re: SSL/TLS still seems to be screwed up (retrieving Mail with Thunderbird)

FromBrandon Vincent <Brandon.Vincent@asu.edu>
Date2016-04-11 00:10 +0200
SubjectRe: SSL/TLS still seems to be screwed up (retrieving Mail with Thunderbird)
Message-ID<rmvIm-3z5-9@gated-at.bofh.it>
In reply to#4676
On Sun, Apr 10, 2016 at 9:22 AM, Elmar Stellnberger <estellnb@gmail.com> wrote:
>   Is anyone here who can explain the insecurity of SSL/TLS in its current
> state?

TLS properly implemented is secure. The insecure VPN (as you so
describe it) may have been stripping out the offer of STARTTLS by the
IMAP server. This is pretty trivial to do when you control all of the
data flowing through the VPN [1]. This has actually been done by some
ISPs in the past [2].

Although the RFC for STARTTLS indicates that clients should fallback
if TLS is not available [3], last time I checked if you have STARTTLS
specified in the server settings in Thunderbird, it should not be
establishing a connection if it is unable to do so over TLS.

What are the server settings you are using for IMAP?
Was it a successful login or an attempted login?
Did you accept any certificate warnings?

[1] https://github.com/tintinweb/striptls
[2] https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks
[3] https://tools.ietf.org/html/rfc2595

Brandon Vincent

[toc] | [prev] | [next] | [standalone]


#4678

FromElmar Stellnberger <estellnb@gmail.com>
Date2016-04-11 08:30 +0200
Message-ID<rmDwd-1lv-3@gated-at.bofh.it>
In reply to#4677

Am 2016-04-11 um 00:00 schrieb Brandon Vincent:
> TLS properly implemented is secure. The insecure VPN (as you so
> describe it) may have been stripping out the offer of STARTTLS by the
> IMAP server. This is pretty trivial to do when you control all of the
> data flowing through the VPN [1]. This has actually been done by some
> ISPs in the past [2].
>
> Although the RFC for STARTTLS indicates that clients should fallback
> if TLS is not available [3], last time I checked if you have STARTTLS
> specified in the server settings in Thunderbird, it should not be
> establishing a connection if it is unable to do so over TLS.
>
> What are the server settings you are using for IMAP?
SSL/TLS (not starttls)
password, normal
imap.gmail.com

> Was it a successful login or an attempted login?
I do not know it for certain. At least there was no popup-error message. 
However there could have been a temporary error in the bottom status bar 
without me having read it (I was working on another virtual desktop 
while Thunderbird was open). Perhaps there is some log somewhere where I 
could have a look?

> Did you accept any certificate warnings?
No.


>
> [1] https://github.com/tintinweb/striptls
> [2] https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks
> [3] https://tools.ietf.org/html/rfc2595
>
> Brandon Vincent
>

[toc] | [prev] | [next] | [standalone]


#4679

FromEvgeny Kapun <abacabadabacaba@gmail.com>
Date2016-04-11 09:00 +0200
Message-ID<rmDZg-1wB-9@gated-at.bofh.it>
In reply to#4676
On 10.04.2016 19:22, Elmar Stellnberger wrote:
> my gmail password was malversated within a few seconds; i.e. I got a login attempt from HongKong and had to change the password after disconnecting.

Is it possible that it was YOUR login attempt? Maybe Google detected your login attempt through VPN as coming from Hong Kong and thus blocked it. If this is the case, your account was probably not compromised.

Actually, Google is very suspicious of login attempts from email clients and other non-browser programs. When logging in through a browser, it uses browser fingerprint and a persistent cookie to check that you are logging in from the browser that you usually use, but it can't do that with email clients.

[toc] | [prev] | [next] | [standalone]


#4680

FromElmar Stellnberger <estellnb@gmail.com>
Date2016-04-11 10:20 +0200
Message-ID<rmFeG-2HC-13@gated-at.bofh.it>
In reply to#4679
Am 2016-04-11 um 08:55 schrieb Evgeny Kapun:
> On 10.04.2016 19:22, Elmar Stellnberger wrote:
>> my gmail password was malversated within a few seconds; i.e. I got a
>> login attempt from HongKong and had to change the password after
>> disconnecting.
>
> Is it possible that it was YOUR login attempt? Maybe Google detected
> your login attempt through VPN as coming from Hong Kong and thus blocked
> it. If this is the case, your account was probably not compromised.
>

   Yes, it was actually the login attempt by my Thunderbird instance as 
the VPN was from Hong Kong and the login attempt as well. So this time 
no password had been malversated, definitely. Please excuse the 
irritation. Once you can remember a similar accident you will be 
somewhat more suspicious than necessary.
   Nonetheless the last time I had connected via a similar but more 
suspicious VPN to France I got a similar login attempt via my Google 
account from Vienna, Austria while I was staying in Carinthia and 
connected via Klagenfurt/Austria (where my ISP links to). That time 
there was definitely reason to believe in an attack of my Google account 
and I had my password changed.
   Similarely I had connected once via an unencrypted Wifi in Villach 
and got login attempts from Russia within a few hours afterwards for my 
Google account. Also very suspicious. Unfortunately these accidents will 
likely not be of help for us since they are already about a year or two 
in the past (summer last year; i.e. ~ 1,5 years in the past). I can not 
even remember the server settings from then (though they were likely 
somewhat similar.).
   Anyone here who can remember a hard security issue having been fixed 
for SSL/TLS within the last two years? The heart bleed bug should 
already have been fixed then as that one is from April 2014.


> Actually, Google is very suspicious of login attempts from email clients
> and other non-browser programs. When logging in through a browser, it
> uses browser fingerprint and a persistent cookie to check that you are
> logging in from the browser that you usually use, but it can't do that
> with email clients.

P.S.: Special Thanks to You, Brandon Vincent.
I still had the STARTTLS setting activated for my revido account and 
changed it to SSL/TLS as soon as I had heard how dangerous that might 
be. Unfortunately there are no geographical warnings for login attempts 
from the revido account (Accordings to ¿German law? they do not even 
expose me their server log cotaining the IPs with login attempts which 
could be backtraced with geoip). I`d personally believe that 
unsuspecting users should be warned of the fallback option of STARTTLS 
as it sounds like TLS but it can start an unencrypted connection as well.

[toc] | [prev] | [next] | [standalone]


#4681 — Re: SSL/TLS still seems to be screwed up (retrieving Mail with Thunderbird)

FromVladislav Kurz <vladislav.kurz@webstep.net>
Date2016-04-11 11:30 +0200
SubjectRe: SSL/TLS still seems to be screwed up (retrieving Mail with Thunderbird)
Message-ID<rmGkq-3sC-5@gated-at.bofh.it>
In reply to#4680
On Monday 11 of April 2016 Elmar Stellnberger <estellnb@gmail.com> wrote:

>    Nonetheless the last time I had connected via a similar but more
> suspicious VPN to France I got a similar login attempt via my Google
> account from Vienna, Austria while I was staying in Carinthia and
> connected via Klagenfurt/Austria (where my ISP links to). That time
> there was definitely reason to believe in an attack of my Google account
> and I had my password changed.

Hi,

I would not worry myself, if the connection is reported to be from Vienna 
instead of Klagenfurt - it is still from the same country, and GeoIP databases 
are IMHO not very precise. 

But I cannot resist one question - why you use suspicious VPNs at all?

-- 
Best Regards
        Vladislav Kurz

[toc] | [prev] | [next] | [standalone]


#4683

FromElmar Stellnberger <estellnb@gmail.com>
Date2016-04-11 19:30 +0200
Message-ID<rmNOX-11s-41@gated-at.bofh.it>
In reply to#4681
 > But I cannot resist one question - why you use suspicious VPNs at all?
 >
   Well once upon a day I had to notice that I can not upload updates 
for my website (which is at http://www.elstel.org). I noticed that it 
was not possible to ping my webserver, to traceroute it or view web 
pages via http on it; i.e. the server seemed to be down.
   As a consequence I had contacted my web service provider urgently. At 
first I could hardly believe the response that everything was ok, in 
succession I also got the response that my server was reachable from 
several different networks. Consequently the problem was on my side. 
While I was trying a lot of VPNs but could connect to apparently none of 
them while the web pages of major news portals and google were running 
fine I ultimately succeeded to connect to the least trustworthy VPN that 
was available. I should have closed my email program though in advance 
because afterwards I had to change my password.

Am 2016-04-11 um 11:00 schrieb Vladislav Kurz:
>
> Hi,
>
> I would not worry myself, if the connection is reported to be from Vienna
> instead of Klagenfurt - it is still from the same country, and GeoIP databases
> are IMHO not very precise.
>
  I am somehow in doubt that it would not pay off to worry about this. 
Vienna is as far away from my home (Carinthia) as Padua in Italy is 
(230km via air and ~ 300km via road while the way to Padua is less 
montaneouos). Laibach (Slovenia) is even more close than Graz a major 
city on the way to Vienna. Ultimately I have changed my passwords and I 
would certainly believe that there was reason to do so *.

* There would ultimately be no sense in geodata with sub-country 
granularity if my home is right on the other side of Austria (very in 
the South) than Vienna (in the North of Austria) is.

[toc] | [prev] | [next] | [standalone]


#4684 — Re: SSL/TLS still seems to be screwed up (retrieving Mail with Thunderbird)

FromVaughn Graham <vaughng@dmsllconline.net>
Date2016-04-11 21:00 +0200
SubjectRe: SSL/TLS still seems to be screwed up (retrieving Mail with Thunderbird)
Message-ID<rmPe3-21s-41@gated-at.bofh.it>
In reply to#4683

[Multipart message — attachments visible in raw view] — view raw

>
> Well once upon a day I had to notice that I can not upload updates for my
> website (which is at http://www.elstel.org). I noticed that it was not
> possible to ping my webserver, to traceroute it or view web pages via http
> on it; i.e. the server seemed to be down.


It is not that uncommon for some services to block VPN and public
forwarding services, A number of the companies I have worked with have this
as a policy. It may not really help that much, but it have made it in some
admins standard toolbox.

As others have said geofencing is quite unreliable, I am in the US and I
never show as in the area I live in at least a few hundred miles away, and
this is going to be even less reliable as time goes on with companies and
countries starting to lease/sell IPv4 space, poorly documented and
geofencing services not updating as this happens.



On Mon, Apr 11, 2016 at 12:28 PM, Elmar Stellnberger <estellnb@gmail.com>
wrote:

> > But I cannot resist one question - why you use suspicious VPNs at all?
> >
>   Well once upon a day I had to notice that I can not upload updates for
> my website (which is at http://www.elstel.org). I noticed that it was not
> possible to ping my webserver, to traceroute it or view web pages via http
> on it; i.e. the server seemed to be down.
>   As a consequence I had contacted my web service provider urgently. At
> first I could hardly believe the response that everything was ok, in
> succession I also got the response that my server was reachable from
> several different networks. Consequently the problem was on my side. While
> I was trying a lot of VPNs but could connect to apparently none of them
> while the web pages of major news portals and google were running fine I
> ultimately succeeded to connect to the least trustworthy VPN that was
> available. I should have closed my email program though in advance because
> afterwards I had to change my password.
>
> Am 2016-04-11 um 11:00 schrieb Vladislav Kurz:
>
>>
>> Hi,
>>
>> I would not worry myself, if the connection is reported to be from Vienna
>> instead of Klagenfurt - it is still from the same country, and GeoIP
>> databases
>> are IMHO not very precise.
>>
>>  I am somehow in doubt that it would not pay off to worry about this.
> Vienna is as far away from my home (Carinthia) as Padua in Italy is (230km
> via air and ~ 300km via road while the way to Padua is less montaneouos).
> Laibach (Slovenia) is even more close than Graz a major city on the way to
> Vienna. Ultimately I have changed my passwords and I would certainly
> believe that there was reason to do so *.
>
> * There would ultimately be no sense in geodata with sub-country
> granularity if my home is right on the other side of Austria (very in the
> South) than Vienna (in the North of Austria) is.
>
>
>
>
>
>
>


-- 
-
    *Vaughn Graham*
    *Director of E-Innovations*
    Domino Management Services LLC.

[toc] | [prev] | [next] | [standalone]


#4685

FromElmar Stellnberger <estellnb@gmail.com>
Date2016-04-11 21:20 +0200
Message-ID<rmPxn-2uZ-5@gated-at.bofh.it>
In reply to#4684

Am 2016-04-11 um 20:50 schrieb Vaughn Graham:
>     Well once upon a day I had to notice that I can not upload updates
>     for my website (which is at http://www.elstel.org
>     <http://www.elstel.org/>). I noticed that it was not possible to
>     ping my webserver, to traceroute it or view web pages via http on
>     it; i.e. the server seemed to be down.
>
>
> It is not that uncommon for some services to block VPN and public
> forwarding services, A number of the companies I have worked with have
> this as a policy. It may not really help that much, but it have made it
> in some admins standard toolbox.
>
  No, these strange problems did not occur inside a VPN but via the 
normal internet connection via my ISP which is Telekom Austria. In a 
fact they were eliminated by the VPN which I suspect to have grabbed my 
email password. If I say that I could not connect for the many VPNs 
listed at http://www.vpngate.net/api/iphone which are known to work 
grosso modo without problems otherwise then I also tried to connect via 
the 'normal internet access' as provided by my ISP.

> As others have said geofencing is quite unreliable, I am in the US and I
> never show as in the area I live in at least a few hundred miles away,
> and this is going to be even less reliable as time goes on with
> companies and countries starting to lease/sell IPv4 space, poorly
> documented and geofencing services not updating as this happens.
   May be right though all geofencing data Google uses for Austria would 
then be rather useless or detremential; I still note the coincidence in 
time because I was never reported any inconsistent login attempts via 
Vienna while being in Carinthia before (during many years).

[toc] | [prev] | [next] | [standalone]


#4688 — Re: SSL/TLS still seems to be screwed up (retrieving Mail with Thunderbird)

FromBrandon Vincent <Brandon.Vincent@asu.edu>
Date2016-04-12 05:20 +0200
SubjectRe: SSL/TLS still seems to be screwed up (retrieving Mail with Thunderbird)
Message-ID<rmX1T-8X-1@gated-at.bofh.it>
In reply to#4684
On Mon, Apr 11, 2016 at 11:50 AM, Vaughn Graham
<vaughng@dmsllconline.net> wrote:
> As others have said geofencing is quite unreliable, I am in the US and I
> never show as in the area I live in at least a few hundred miles away, and
> this is going to be even less reliable as time goes on with companies and
> countries starting to lease/sell IPv4 space, poorly documented and
> geofencing services not updating as this happens.

Traditional geolocation is pretty bad. Usually such attempts are just
matched against regional Internet registry records.

There are services available that can pinpoint your geographical
location much more accurately through data analytics. Since most ISPs
rarely change the IP blocks associated with neighborhoods/cities, a
lot of services use data collected from a variety of ads/sources
(including requests for weather, direction services, subscriptions
etc.) to determine your location far more accurately. Try out the
following (if you live within the United States, you'll probably be
shocked at the accuracy):

http://ipinfo.io
https://www.maxmind.com/en/locate-my-ip-address

Brandon Vincent

[toc] | [prev] | [next] | [standalone]


#4682 — Re: SSL/TLS still seems to be screwed up (retrieving Mail with Thunderbird)

FromBrandon Vincent <Brandon.Vincent@asu.edu>
Date2016-04-11 15:00 +0200
SubjectRe: SSL/TLS still seems to be screwed up (retrieving Mail with Thunderbird)
Message-ID<rmJBE-655-27@gated-at.bofh.it>
In reply to#4680
On Mon, Apr 11, 2016 at 1:10 AM, Elmar Stellnberger <estellnb@gmail.com> wrote:
> I still had the STARTTLS setting activated for my revido account and changed
> it to SSL/TLS as soon as I had heard how dangerous that might be.
> Unfortunately there are no geographical warnings for login attempts from the
> revido account (Accordings to ¿German law? they do not even expose me their
> server log cotaining the IPs with login attempts which could be backtraced
> with geoip). I`d personally believe that unsuspecting users should be warned
> of the fallback option of STARTTLS as it sounds like TLS but it can start an
> unencrypted connection as well.

Implemented properly it shouldn't matter which option you pick. The
SSL/TLS option is actually depreciated. Thunderbird should refuse a
connection if you have STARTTLS checked and the server doesn't support
it. It sounds more like your login was what was throwing the alert.
The best advice I can offer is to not use an "untrusted" VPN. Free VPN
services have to make money somehow.

Brandon Vincent

[toc] | [prev] | [next] | [standalone]


#4686

FromElmar Stellnberger <estellnb@gmail.com>
Date2016-04-11 21:50 +0200
Message-ID<rmQ0q-2ML-17@gated-at.bofh.it>
In reply to#4682
Am 2016-04-11 um 14:51 schrieb Brandon Vincent:
> Implemented properly it shouldn't matter which option you pick. The
> SSL/TLS option is actually depreciated. Thunderbird should refuse a
> connection if you have STARTTLS checked and the server doesn't support
> it. It sounds more like your login was what was throwing the alert.

For the Hong Kong VPN, yes. That one was ok.
... but what about the unencrypted Wifi in Villach, Austria I had used 
after which I got login attempts from Russia. Google Mail accounts are 
encrypted since long (1,5 years in the past; i.e. that was last summer 
when I remember it correctly.); possibly I will have to look if I still 
have the Google warning; now I want to see the proof for it myself once 
more ...

> The best advice I can offer is to not use an "untrusted" VPN. Free VPN
> services have to make money somehow.
>
> Brandon Vincent
>

The question always is on how much you trust your ISP and the internet 
connection you have. If a site is not available by my ISP I perhaps 
wanna try it via a VPN or Tor. Otherwise we would not need sites like 
downforeveryoneorjustme.com.

Some of my friends do also complain not to receive emails from me or I 
do not receive emails they told me afterwards that they would have 
written me. This is usually due to spam settings but I for my revido 
account have disabled any spam deletion or trashing so that every 
message considered spam still will arrive at my inbox (flagged as spam 
though). Why there are still emails lost every now and then remains ominous.

Finally some relatives of mine have once told me that a link on my own 
site http://www.elstel.org/MH17.html.de would not work. I just popped up 
my browser and verified that the link was in deed working from me and 
the net my ISP provides to me (yes; this time it was the other way 
round). The message behind the link was somehow politically delicate 
claiming that the West would try to provoke a war with Russia (in the 
meantime this site has resettled to de.sputniknews.com, though that time 
when my relatives had complaint it had not yet resettled (i.e. the link 
may be dead when you test it nowadays but that time it was not.).).

Elmar Stellnberger

[toc] | [prev] | [next] | [standalone]


#4687

FromElmar Stellnberger <estellnb@gmail.com>
Date2016-04-11 22:50 +0200
Message-ID<rmQWu-3to-19@gated-at.bofh.it>
In reply to#4686
Am 2016-04-11 um 21:40 schrieb Elmar Stellnberger:
> have the Google warning; now I want to see the proof for it myself once
> more ...
>
   Unfortunately I found two login attempts from 2015 on 1.November 
10:44 (likely that of the VPN) from Vienna and on 30.August 2015 22:58 
from Vienna / Safari. I was not in Vienna 2014/2015. Another one from 
2014-08-07 where I was in Villach and it correctly says that I had 
logged in in Villach. Nonetheless all of it too old and too long in the 
past to tell anything definitely about it. I remember that there was 
something with a Russian login as well but I did not find it; likely 
even more old. Still thanks for your attention!

P.S.: The other issue about the server non reachable from my ISP may 
more likely be worth the discussion.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.security


csiph-web