-1

My employer's clients are trying to download a file from our internetbanking application over ssl. When downloading with internet explorer, in some cases it shows an error

"-1 from url cannot be downloaded. This server in internet can not be opened. Requested server is not available"

When downloading with Chrome, everything seems ok. I suppose it is problem on client pc, because in application log on server, everything seems ok. Clients tried to delete temporary internet files and cookies, but without success.

Anyone have any suggestions where cause could be ?

5
  • What version of Internet Explorer, and Windows? Jul 15, 2015 at 8:28
  • Whats the IE version, because if the bank SSL server chipers are writen so older IE versions do not work then you get that kind of error.
    – cr0c
    Jul 15, 2015 at 8:39
  • IE is version 9 and windows 7
    – Jan Bohac
    Jul 15, 2015 at 8:43
  • You may be wrong that it's the client's fault. The client may be (quite rightly) rejecting an ephemeral DH key that is export grade used with a symmetric cipher that is stronger. It is probably either IE's fix for logjam or OpenSSL's fix for logjam. Does your application use OpenSSL? If so, what OpenSSL version are you using? Does your application customize the generation of ephemeral DH keys (by calling SSL_CTX_set_tmp_dh_callback)? Jul 15, 2015 at 9:45
  • Any chance it's support.microsoft.com/en-us/kb/2549423 ?
    – fmoo
    Nov 19, 2015 at 6:53

1 Answer 1

0

This is largely a guess, and I'll refine it as you answer some of the questions I asked.

There's an attack on TLS called logjam, where an ephemeral DH key that is way too weak is used to transport the symmetric key. IE is not vulnerable and will close the connection if the DH key is export grade (less than 1,024 bits) when the symmetric cipher is strong.

Some applications cause this situation by providing only a 512-bit ephemeral DH key even if a non-export symmetric cipher is used. This provides very little security, and IE rightly rejects it. Likely other browsers soon will too.

You need to look at how your application's TLS layer generates ephemeral DH keys. If it only has 512-bit parameters, you should immediately add support for 1024-bit parameters and use the 512-bit parameters only with export ciphers (or remove them if you don't support export ciphers).

If you're using OpenSSL, look at your calls to functions that control the selection of the ephemeral DH key. It may be sufficient to upgrade OpenSSL to a current version not vulnerable to logjam and modify your application not to call any of these functions. However, you should probably have a competent security expert review your mechanism for selecting the ephemeral DH key and make sure it's not vulnerable to logjam or broken completely (say by always using a 512-bit key).

2
  • Thank you for answer. I bet application uses sufficiently strong dh key, because i tested this on ie 11 with security patch support.microsoft.com/en-us/kb/3061518, which updates ie to accept only key length of 1024 bits and it downloaded file succesfully
    – Jan Bohac
    Jul 15, 2015 at 10:35
  • Then I'd suggest capturing the traffic of the failed connection attempt and analyzing it. Jul 15, 2015 at 17:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .