How to verify IIS, Apache & SMTP is vulnerable to Logjam

Can I use  openssl cliengt command to verify if our IIS, Apache are vulnerable?
What's the exact syntax/command?  
Is it "openssl s_client -connect IP_addr:443"   ?

Are TLS1.0, TLS1.1 or TLS1.2 vulnerable?

How do I verify our SMTP (Linux customized sendmail) is vulnerable?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

sunhuxAuthor Commented:
For SMTP test, what's given in the link doesn't quite work for me
(though for SSL websites, this same openssl.exe utility works):

C:\Openssl102>openssl s_client -connect -starttls smtp -cipher "EDH
" -
WARNING: can't open config file: /usr/local/ssl/openssl.cnf
unknown option -
usage: s_client args

 -host host     - use -connect instead
 -port port     - use -connect instead
 -connect host:port - who to connect to (default is localhost:4433)
 -verify_host host - check peer certificate matches "host"
 -verify_email email - check peer certificate matches "email"
 -verify_ip ipaddr - check peer certificate matches "ipaddr"
 -verify arg   - turn on peer certificate verification
 -verify_return_error - return verification errors
 -cert arg     - certificate file to use, PEM format assumed
 -certform arg - certificate format (PEM or DER) PEM default
 -key arg      - Private key file to use, in cert file if
                 not specified but cert file is.
 -keyform arg  - key format (PEM or DER) PEM default
 -pass arg     - private key file pass phrase source
 -CApath arg   - PEM format directory of CA's
 -CAfile arg   - PEM format file of CA's
 -reconnect    - Drop and re-make the connection with the same Session-ID
 -pause        - sleep(1) after each read(2) and write(2) system call
 -prexit       - print session information even on connection failure
 -showcerts    - show all certificates in the chain
 -debug        - extra output
 -msg          - Show protocol messages
 -nbio_test    - more ssl protocol testing
 -state        - print the 'ssl' states
 -nbio         - Run with non-blocking IO
 -crlf         - convert LF from terminal into CRLF
 -quiet        - no s_client output
 -ign_eof      - ignore input eof (default when -quiet)
 -no_ign_eof   - don't ignore input eof
 -psk_identity arg - PSK identity
 -psk arg      - PSK in hex (without 0x)
 -srpuser user     - SRP authentification for 'user'
 -srppass arg      - password for 'user'
 -srp_lateuser     - SRP username into second ClientHello message
 -srp_moregroups   - Tolerate other than the known g N values.
 -srp_strength int - minimal length in bits for N (default 1024).
 -ssl2         - just use SSLv2
 -ssl3         - just use SSLv3
 -tls1_2       - just use TLSv1.2
 -tls1_1       - just use TLSv1.1
 -tls1         - just use TLSv1
 -dtls1        - just use DTLSv1
 -fallback_scsv - send TLS_FALLBACK_SCSV
 -mtu          - set the link layer MTU
 -no_tls1_2/-no_tls1_1/-no_tls1/-no_ssl3/-no_ssl2 - turn off that protocol
 -bugs         - Switch on all SSL implementation bug workarounds
 -serverpref   - Use server's cipher preferences (only SSLv2)
 -cipher       - preferred cipher to use, use the 'openssl ciphers'
                 command to see what is available
 -starttls prot - use the STARTTLS command before starting TLS
                 for those protocols that support it, where
                 'prot' defines which one to assume.  Currently,
                 only "smtp", "pop3", "imap", "ftp" and "xmpp"
                 are supported.
 -engine id    - Initialise and use the specified engine
 -rand file;file;...
 -sess_out arg - file to write SSL session to
 -sess_in arg  - file to read SSL session from
 -servername host  - Set TLS extension servername in ClientHello
 -tlsextdebug      - hex dump of all TLS extensions received
 -status           - request certificate status from server
 -no_ticket        - disable use of RFC4507bis session tickets
 -serverinfo types - send empty ClientHello extensions (comma-separated numbers)

 -nextprotoneg arg - enable NPN extension, considering named protocols supported
 (comma-separated list)
 -alpn arg         - enable ALPN extension, considering named protocols supporte
d (comma-separated list)
 -legacy_renegotiation - enable use of legacy renegotiation (dangerous)
 -use_srtp profiles - Offer SRTP key management with a colon-separated profile l
 -keymatexport label   - Export keying material using label
 -keymatexportlen len  - Export len bytes of keying material (default 20)
sunhuxAuthor Commented:
So are TLSv1.0 or TLSv1.1 vulnerable?

Looks like the openssl command I used previously is meant for Linux openssl.

Windows openssl has different syntax but I still don't know how to interpret if
the output below means it's vulnerable or otherwise:

C:\Openssl102>openssl s_client -connect -tls1_1
-cipher "EDH"

1148:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:.
\ssl\s3_pkt.c:1456:SSL alert number 40
1148:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:.\ssl\s3
no peer certificate available
No client certificate CA names sent
SSL handshake has read 7 bytes and written 0 bytes
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
    Protocol  : TLSv1.1
    Cipher    : 0000
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1432922310
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

btanExec ConsultantCommented:
Logjam is about using DHE of 512 bits, minimally we are saying it is used as key exchanges). I believe you know that so if using DHE or even by listing the cipher supported, it should be able to identify this CVE-2015-4000 (aka LogJam). The testing you stated is on checking for ECDHE which does not ECC DH which is >than 512 bits. It will good to test for both
e.g ..... (-cipher "ECDHE") and look out for "Server Temp Key" (using grep if in linux)
> connection should fail.
e.g. ....(-cipher "EXP")  
> connections with keys shorter than 1024 bits may already be in trouble today. (Note: you need OpenSSL 1.0.2. Earlier versions of the client do not display this information.)
See more in

another easier means is using ssllab test online svc if the site is live eg.

It will show "This server supports insecure Diffie-Hellman (DH) key exchange parameters. Grade set to F." if it suffers from LogJam. Looks fine for the ebanking site above.

or another (may be more direct to reading) is
It will show "Safe! The domain is not vulnerable to TLS Logjam attacks." if it is free from the CVE and will highlight weak cipher

Do check out the sysadmin guide on enabling cipher for each server type
"Guide to Deploying Diffie-Hellman for TLS" -

A1: Yes, the syntax, already shared above in the openssl blog and for nmap it is
e.g. nmap --script ssl-enum-ciphers -p 443 (and look for "EXPORT")
For info, 1.0.2 s_client will displays "Temp server key" DHE and its key size if supported. For ECDH and curve if it is supported and then be applicable. They are displayed just before "handshake has read x and written y", and just look out for it if they are supported. May be easier to "decode" relevance of key exchange for FS. If the connections fails straight away, then the server does not support ephemeral Diffie-Hellman.

A2: If TLS1.0, TLS1.1 or TLS1.2 support DHE then they are vulnerable, trust and verify..CVE states:
The TLS protocol 1.2 and earlier, when a DHE_EXPORT ciphersuite is enabled on a server but not on a client, does not properly convey a DHE_EXPORT choice, which allows man-in-the-middle attackers to conduct cipher-downgrade attacks by rewriting a ClientHello with DHE replaced by DHE_EXPORT and then rewriting a ServerHello with DHE_EXPORT replaced by DHE, aka the “Logjam” issue.

Check out the NIST 800-52 (pdf) for the TLS recommendation - see section 3.3.1 Cipher Suites which summarises for the TLS 1.0, 1.1 and 1.2. A 2048-bit DHE group is generally still acceptable and ECDH is preferable.

A3: use openssl with its -msg option below and it will shows the full TLS ServerKeyExchange message.
e.g. openssl s_client -connect -starttls imap -cipher EDH -msg
An example from the forum sharing
<<< TLS 1.2 Handshake [length 030f], ServerKeyExchange
    0c 00 03 0b 01 00 ff ff ff ff ff ff ff ff c9 0f
    da a2 21 68 c2 34 c4 c6 62 8b 80 dc 1c d1 29 02
    4e 08 8a 67 cc 74 02 0b be a6 3b 13 9b 22 51 4a
and interpretation as stated too
>0c 00 03 0b: message of type "ServerKeyExchange" (that's the "0c") of length 0x00030B bytes.
>First element is the DH modulus as a big integer, with a two-byte length header. Here, the length is encoded as 01 00, meaning an integer encoded over 0x0100 bytes. That's 256 bytes, so the modulus has length between 2041 and 2048 bits.
>The modulus bytes follow, in unsigned big-endian order. The top bytes of that modulus are, in this case, ff ff ff ff.... The modulus then has length exactly 2048 bits.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
sunhuxAuthor Commented:
C:\Openssl102> openssl s_client -connect -starttls imap -cipher EDH -msg

Loading 'screen' into random state - done
didn't found STARTTLS in server response, try anyway...
>>> TLS 1.2  [length 0005]
    16 03 01 00 8c
>>> TLS 1.2 Handshake [length 008c], ClientHello
    01 00 00 88 03 03 b6 de f1 f7 ce c0 b0 ca e2 86
    . . .
    03 02 01 02 02 02 03 00 0f 00 01 01
no peer certificate available
No client certificate CA names sent
SSL handshake has read 0 bytes and written 171 bytes
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
btanExec ConsultantCommented:
the site tested does no DH and EDH, it used RSA for key exchange. Hence, No Forward Secrecy too. Not affected by LogJam. Note that IMAP is via 143 (non-SSL) and 993 for (SSL based), not 443. You can try CheckTLS -
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.