Disabling Cipher Suites

I am trying to disable cipher suites on Weblogic Server 8.1. Does anyone know how to do this?
For example, if I want to disable the cipher suite "TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA" how would I do it?
We are trying to restrict clients to only use certiain cipher suites that ensure a high key length. By disabling certain cipher suites we can restrict the "less secure" sessions.
Thanks!
Rob

I found it. In the config.xml under SSL, there is a setting for "Ciphersuites".
Thanks!
Rob

Similar Messages

  • SSL cipher suites with v3

    Any way to adjust which SSL cipher suites are used with the messaging agent on version 3 of messenger? There are a few that are not compatible with our firewall and we need to disable them. It's keeping iOS clients from connecting.

    Palo Alto Networks firewall. We enforce SSL decryption on all traffic and any suite that uses Diffie-Hellman key exchange isn't supported. Has to be RSA key exchange.
    Originally Posted by ahidalgo
    Which SSL cipher suites are not compatible with your firewall, just curious. Whose firewall are you using?
    Al
    On 2/27/2015 at 9:26 PM, jarrodholder<[email protected]> wrote:
    Any way to adjust which SSL cipher suites are used with the messaging
    agent on version 3 of messenger? There are a few that are not
    compatible with our firewall and we need to disable them. It's keeping
    iOS clients from connecting.
    jarrodholder
    jarrodholder's Profile: https://forums.novell.com/member.php?userid=1616
    View this thread: https://forums.novell.com/showthread.php?t=482111

  • Cisco Prime Infrastucture vulnerability SSL RC4 Cipher Suites Supported

    Hi All,
    I have a question on how to disable RC4 Cipher Suites Supported on Cisco Prime Infrastructure Platform.
    My Client have use Nessus Software to scan on prime. and found on below vulnerability
    SSL RC4 Cipher Suites Supported
    Cisco prime infrastructure deploy on latest 2.1
    we have gain the root access and modifier the ssl.conf and restart the service also unable to solve.
    /opt/CSCOlumos/httpd/ssl/backup/ssl.conf
    /opt/CSCOlumos/httpd/ssl/ssl.conf
    C:\Program Files\Tenable\Nessus>nessuscmd -v -p 443 -i 21643 192.168.1.55
    Starting nessuscmd 5.2.7
    Scanning '192.168.1.55'...
    Host 192.168.1.55 is up
    Discovered open port https (443/tcp) on 192.168.1.55
    [i] Plugin 21643 reported a result on port https (443/tcp) of 192.168.1.55
    + Results found on 192.168.1.55 :
       - Port https (443/tcp) is open
         [i] Plugin ID 21643
          | Here is the list of SSL ciphers supported by the remote server :
          | Each group is reported per SSL Version.
          | SSL Version : TLSv1
          |   Medium Strength Ciphers (>= 56-bit and < 112-bit key)
          |       DES-CBC-SHA                  Kx=RSA         Au=RSA      Enc=DES-C
          | C(56)          Mac=SHA1
          |       RC4-MD5                      Kx=RSA         Au=RSA      Enc=RC4(1
          | 8)             Mac=MD5
          |       RC4-SHA                      Kx=RSA         Au=RSA      Enc=RC4(1
          | 8)             Mac=SHA1
          |
          | SSL Version : SSLv3
          |   Medium Strength Ciphers (>= 56-bit and < 112-bit key)
          |       DES-CBC-SHA                  Kx=RSA         Au=RSA      Enc=DES-C
          | C(56)          Mac=SHA1
          |       DES-CBC-SHA                  Kx=RSA         Au=RSA      Enc=DES-C
          | C(56)          Mac=SHA1
          |   High Strength Ciphers (>= 112-bit key)
          |       EDH-RSA-DES-CBC3-SHA         Kx=DH          Au=RSA      Enc=3DES(
          | 68)            Mac=SHA1
          |       RC4-MD5                      Kx=RSA         Au=RSA      Enc=RC4(1
          | 8)             Mac=MD5
          |       RC4-SHA                      Kx=RSA         Au=RSA      Enc=RC4(1
          | 8)             Mac=SHA1
          | The fields above are :

    Hi ,
    "SSL RC4 Cipher Suites Supported" has been documented in bug CSCum03709. 
    CSCum03709    PI 2.0.0.0.294 with SSH vulnerabilities
    Presently, there is no workaround for this vulnerability, however, the fix will be implemented in
    Prime Infrastructure 2.2.which is planned to be released around the end of this year ( tentative)
    Thanks-
    Afroz
    ***Ratings Encourages Contributors ***

  • How can I control the list of cipher suites offered in the SSL Client Hello message? I want to forbid MD5 and RC4.

    How can I control the list of cipher suites offered in the SSL Client Hello message?
    I want to limit my browser to negotiating strong cipher suites. I'd like to forbid DES, MD5 and RC4.

    Set the related SSL3 prefs to false on the about:config page (Filter: security.ssl3.).
    *http://kb.mozillazine.org/about:config

  • Setting cipher suite name in Httprequest header

    Is it possible to set the cipher suite name in http request header ?

    The cipher suite has nothing to do with HTTP. Ciphersuites are only negotiated by the SSL/TLS peers.

  • Handshake_failure (no cipher suites in common) error

    Requirement
    1. Login to a HTTPS site with the given site username and password through a proxy server (Proxy server doesn't require authentication)
    2. Then upload a document in the site
    Jars used
    jsse.jar
    Jcert.jar
    Jnet.jar
    Environment
    Unix \ Weblogic
    Code
    import java.io.*;
    import java.net.*;
    import java.util.*;
    import java.security.*;
    import javax.net.ssl.*;
    String loginURL = config.getProperty("LoginURL");
    String putURL = config.getProperty("PutURL");
    // This is where we have stored the certificate from the server using keytool
    //keytool -import -alias ca -file xxx.cer -trustcacerts -v -keystore "cacerts"
    //Stored the certificate by viewing the site throw the browser and save it locally
    String certFile = config.getProperty("GetCertpath");
    // Set proxy
    System.setProperty("https.proxyHost", config.getProperty("Proxy"));
    System.setProperty("https.proxyPort", config.getProperty("ProxyPort"));
    Security.addProvider( new com.sun.net.ssl.internal.ssl.Provider() );
    System.setProperty("java.protocol.handler.pkgs", "com.sun.net.ssl.internal.www.protocol");
    // We are overriding the system default trust store
    System.setProperty( "javax.net.ssl.trustStore", certFile);
    URL dataURL = new URL(null, loginURL, new com.sun.net.ssl.internal.www.protocol.https.Handler());
    com.sun.net.ssl.HttpsURLConnection connection = (com.sun.net.ssl.HttpsURLConnection) dataURL.openConnection();
    connection.setHostnameVerifier(new HostnameVerifierImpl());
    connection.setInstanceFollowRedirects(true); // Follow redirects by host
    // Create login header
    String hostlogin = config.getProperty("userID") + ":" + config.getProperty("password");
    String encodedHostLogin = Base64Converter.encode(hostlogin.getBytes());
    connection.setRequestProperty("Authorization", "Basic " + encodedHostLogin);
    // Get the cookie. We'll need it to maintain the session
    cookie = connection.getHeaderField("Set-Cookie");
    // Read the host's reply, and dump
    BufferedReader in = new BufferedReader(new InputStreamReader(connection.getInputStream())); //ERROR at this point
    //System.out.print("## INFO: Host Replied...");
    String line = null;
    while((line = in.readLine()) != null)
    //System.out.println(line);
    in.close();
    Error Dump
    Exception occured Received fatal alert: handshake_failure (no cipher suites in common)
    javax.net.ssl.SSLException: Received fatal alert: handshake_failure (no cipher suites in common)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b([DashoPro-V1.2-120198])
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a([DashoPro-V1.2-120198])
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a([DashoPro-V1.2-120198])
    at com.sun.net.ssl.internal.ssl.AppOutputStream.write([DashoPro-V1.2-120198])
    at java.io.OutputStream.write(OutputStream.java:56)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake([DashoPro-V1.2-120198])
    at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.doConnect([DashoPro-V1.2-120198])
    at com.sun.net.ssl.internal.www.protocol.https.NetworkClient.openServer([DashoPro-V1.2-120198])
    at com.sun.net.ssl.internal.www.protocol.https.HttpClient.l([DashoPro-V1.2-120198])
    at com.sun.net.ssl.internal.www.protocol.https.HttpClient.<init>([DashoPro-V1.2-120198])
    at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.<init>([DashoPro-V1.2-120198])
    at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.a([DashoPro-V1.2-120198])
    at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.a([DashoPro-V1.2-120198])
    at com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnection.connect([DashoPro-V1.2-120198])
    at com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnection.getInputStream([DashoPro-V1.2-120198])
    Questions
    1. The client (we\our application) does not have any certificates. We just have to login to the site with the id and password and upload a file. What extra we should do to avoid this error?

    This is the full debug info
    *** ClientHello, v3.1
    RandomCookie: GMT: 1061973650 bytes = { 66, 125, 28, 182, 32, 174, 11, 166, 105, 30, 208, 142, 122, 250, 76, 48, 46, 41, 230, 73, 229, 20, 7, 5, 25, 218, 181, 43 }
    Session ID: {}
    Cipher Suites: { 0, 3, 0, 17 }
    Compression Methods: { 0 }
    [write] MD5 and SHA1 hashes: len = 47
    0000: 01 00 00 2B 03 01 3F 4C 6F 92 42 7D 1C B6 20 AE ...+..?Lo.B... .
    0010: 0B A6 69 1E D0 8E 7A FA 4C 30 2E 29 E6 49 E5 14 ..i...z.L0.).I..
    0020: 07 05 19 DA B5 2B 00 00 04 00 03 00 11 01 00 .....+.........
    main, WRITE: SSL v3.1 Handshake, length = 47
    [write] MD5 and SHA1 hashes: len = 50
    0000: 01 03 01 00 09 00 00 00 20 00 00 03 02 00 80 00 ........ .......
    0010: 00 11 3F 4C 6F 92 42 7D 1C B6 20 AE 0B A6 69 1E ..?Lo.B... ...i.
    0020: D0 8E 7A FA 4C 30 2E 29 E6 49 E5 14 07 05 19 DA ..z.L0.).I......
    0030: B5 2B .+
    main, WRITE: SSL v2, contentType = 22, translated length = 16337
    main, READ: SSL v3.1 Alert, length = 2
    main, RECV SSLv3 ALERT: fatal, handshake_failure
    %% No cached client session
    *** ClientHello, v3.1
    RandomCookie: GMT: 1061973650 bytes = { 2, 6, 51, 93, 63, 135, 69, 177, 206, 97, 223, 48, 244, 40, 179, 108, 54, 67, 148, 76, 251, 197, 152, 112, 73, 142, 206, 13 }
    Session ID: {}
    Cipher Suites: { 0, 3, 0, 17 }
    Compression Methods: { 0 }
    [write] MD5 and SHA1 hashes: len = 47
    0000: 01 00 00 2B 03 01 3F 4C 6F 92 02 06 33 5D 3F 87 ...+..?Lo...3]?.
    0010: 45 B1 CE 61 DF 30 F4 28 B3 6C 36 43 94 4C FB C5 E..a.0.(.l6C.L..
    0020: 98 70 49 8E CE 0D 00 00 04 00 03 00 11 01 00 .pI............
    main, WRITE: SSL v3.1 Handshake, length = 47
    [write] MD5 and SHA1 hashes: len = 50
    0000: 01 03 01 00 09 00 00 00 20 00 00 03 02 00 80 00 ........ .......
    0010: 00 11 3F 4C 6F 92 02 06 33 5D 3F 87 45 B1 CE 61 ..?Lo...3]?.E..a
    0020: DF 30 F4 28 B3 6C 36 43 94 4C FB C5 98 70 49 8E .0.(.l6C.L...pI.
    0030: CE 0D ..
    main, WRITE: SSL v2, contentType = 22, translated length = 16337
    main, READ: SSL v3.1 Alert, length = 2
    main, RECV SSLv3 ALERT: fatal, handshake_failure
    Exception in thread "main" javax.net.ssl.SSLException: Received fatal alert: handshake_failure (no cipher suites in common)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b([DashoPro-V1.2-120198])
         at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a([DashoPro-V1.2-120198])
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a([DashoPro-V1.2-120198])
    at com.sun.net.ssl.internal.ssl.AppOutputStream.write([DashoPro-V1.2-120198])
    at java.io.OutputStream.write(OutputStream.java:56)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake([DashoPro-V1.2-120198])
    at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.doConnect([DashoPro-V1.2-120198])
    at com.sun.net.ssl.internal.www.protocol.https.NetworkClient.openServer([DashoPro-V1.2-120198])
    at com.sun.net.ssl.internal.www.protocol.https.HttpClient.l([DashoPro-V1.2-120198])
    at com.sun.net.ssl.internal.www.protocol.https.HttpClient.<init>([DashoPro-V1.2-120198])
    at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.<init>([DashoPro-V1.2-120198])
    at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.a([DashoPro-V1.2-120198])
    at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.a([DashoPro-V1.2-120198])
    at com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnection.connect([DashoPro-V1.2-120198])
    at com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnection.getInputStream([DashoPro-V1.2-120198])
    Apart from this,
    1. When we run the same code in the Windows 2000 environment it works.
    2. We want the code to run in the unix box.
    3. We have also placed jsse.jar, jcert.jar and jnet.jar in the jre/lib/ext folder
    4.Took the following existing file "cacerts" from jre/lib/security folder
    5. Saved the certificate from the site through the browser as xxx.cer
    6. Put both the files cacerts and xxx.cer in a directory
    7. Added the xxx.cer to the cacerts using the following command
    keytool -import -alias ca -file xxx.cer -trustcacerts -v -keystore "cacerts"
    8. In the java code set the following property,
    System.setProperty( "javax.net.ssl.trustStore", path to the cacerts file);

  • Transport Layer Security Cipher Suites in Safari

    Does anyone happen to know which Transport Layer Security (TLS) Cipher Suites Safari 4 supports?
    Specifically, does it support the Elliptic Curve suites from RFC 4492? How about AES?
    Thanks!

    Hi,
    i`m only aware that SSL is supported. If you need an official Statement i would recommend you open an OSS Message with the SAP Support.
    Regards
    -Seb.

  • WSMAN CredSSP TLS 1.2 support and cipher suites

    Hi all,
    The protocol document [MS-CSSP] explains the first base64 encoded token send in the authenticate from the client to the server is a TLS Client Hello. The response is a ServerHello.
    The diagram in section 4 'Protocol Examples' of the document indicates the ServerHello has a cipher suite of TLS_RSA_WITH_RC_128_SHA. The TLS version and cipher suites are not mentioned anywhere else in the document.
    So lets take a look a network packet capture of a CredSSP authentication between a winrm.exe client and a Windows 2008 R2 server. I have base64 decoded the contents of the CredSSP Authorization headers,
    The ClientHello bytes (without the extensions) send by my client are:
    16 03 01 00 6B 01 00 00  67 03 01 54 DB 64 77 22 
    A2 1C A3 23 93 61 3B 00  1B DE 1C 6D 42 34 94 8D 
    1D 44 2C 64 8B 42 AC 41  B4 E2 DE 00 00 14 00 2F 
    00 35 00 0A C0 13 C0 14  C0 09 C0 0A 00 32 00 38 
    00 13 01 00 00 2A FF 01  00 01 00 00 00 00 11 00 
    0F 00 00 0C
    Decoding this we can see that this is TLS 1.0 {03, 01}, taking a look at the ciphers we have:
    TLS_RSA_WITH_AES_128_CBC_SHA 0x00 0x2F
    TLS_RSA_WITH_AES_256_CBC_SHA 0x00 0x35
    TLS_RSA_WITH_3DES_EDE_CBC_SHA 0x00,0x0A
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 0xC0,0x13
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 0xC0,0x14
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA 0xC0,0x09
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA 0xC0,0x0A
    TLS_DHE_DSS_WITH_AES_128_CBC_SHA 0x00,0x32
    TLS_DHE_DSS_WITH_AES_256_CBC_SHA 0x00,0x38
    TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 0x00,0x13
    Now lets look at the ServerHello (without the extensions)
    16 03 01 02 3C 02 00 00  4D 03 01 54 DB 64 78 73 
    92 C6 86 A3 F8 FF 3D D4  36 77 C0 FC 80 61 3F 4D 
    8C BC 60 CD BC 4D B1 1C  4A CF 0A 20 DA 14 00 00 
    38 11 DB C9 1C D0 8C 76  E7 A0 B9 F7 A5 D4 94 DF 
    8B 83 38 B3 FF EB AA 65  EB 23 03 0A 00 2F 00 00 
    05 FF 01 00 01 00 0B 00  01 E3 00 01 E0 00 01 DD 
    30 82 01 D9 30 82 01 42  A0 03 02 01 02 02 10 44 
    56 23 69 44 ED 93 85 43  DF B8 DF E3 75 DC A7 30 
    0D 06 09 2A 86 48 86 F7  0D 01 01 05 05 00 30 2B 
    31 29 30 27 06 03 55 04  03 13 20 
    The server responds with TLS 1.0 and selected cipher (0x00 0x2F)
    TLS_RSA_WITH_AES_128_CBC_SHA
    Based on this I created a WSMan CredSSP client using Python and OpenSSL and configured it to use TLS 1.2. I found the Windows server always responded with TLS 1.0. So, I configured my OpenSSL client for TLS 1.0 and set the cipherlist to AES128-SHA (like winrs.exe).
    The CredSSP TLS handshake completes, but the first ASN.1 encoded TSRequest token (containing an NTLM negotiate token) is rejected. However, if my openssl cipherlist is set to RC4, the TSRequest token is accepted and authentication is successful.
    This raises several questions:
    1. Despite sending a TLS 1.2 ClientHello the WSMan CredSSP Server always responded with TLS 1.0 ServerHello. A number of security experts consider this version effectivly broken. Does CredSSP support TLS 1.2?
    2. I can authenticate with CredSSP using openssl 'RC4' cipher suites - but not with AES128-SHA suites. Are suites besides RC4 supported (winrs.exe appears to use AES).
    Thanks
    Ian

    Forum Update:
    I can now answer my 2nd question. The reason CredSSP is rejecting my TSRequest token when using AES128-SHA is because this ciphersuite is using CBC.
    Some years ago OpenSSL added empty fragments to SSLv3 and TLS 1.0 packets to address a potential security vulnerability. These empty fragments are not compatible with Microsofts SChannel implementation so Windows is unable to decrypt the data. OpenSSL added
    a compatibility flag SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS (0x00000800L) that must be set in the openssl client's context options to address this issue with Microsofts implementation. Once I set this option my python openssl client successfully authenticated
    with a Windows 2012 R2 server using ECDHE-RSA-AES256-SHA - much better.
    Question 1 is still unanswered. Is TLS 1.2 with CredSSP supported?

  • Setting cipher suites for ssl sockets

    Hi
    While setting cipher suites for ssl serversocket and socket, there may be lot of stream ciphers and block ciphers in the list. (also there may or may not be anonymous cipher suites).
    How does the ssl socket decide which cipher suite to use?
    Sorry for this newbie question.
    Thank you.

    Have you read the JSSE Reference Guide? It has a really good description of how the SSL handshake works. Part of the "Client Hello" step includes sending all the cipher-suites the client has enabled. The server picks the "best" of that set, that the server also supports, and sends it back as part of the "Server Hello". Both sides switch to that set.
    Now, what "best" means isn't defined. I'm not sure what criteria the server uses to determine that. Maybe someone else reading the thread can chime in.
    Grant

  • How to locate and configure SSL cipher suites

    hi all,
    i wanted to knw how Ciphersuites that are used in SSL Connections are picked up by the JVM or whoever is responsible for establishing the connection at lower level. I mean there are methods in SSLSocketFactory, HttpsURLConnection named getEnabledCipherSuites(). I was just wondering where these default cipher suites are picked up. Is there any configuration file or some setting where we can add our own cipher suite to the list?
    Please advice.
    Thanks in advance :)
    Arun

    hi,
    As already we have discussed this, we can set the ciphersuite used in the SSLConnection using SSLSocket.setEnabledCIpherSuite() function only. And getSupportedCipherSuites() function returns the list of cipher suites that are supported by the connection.
    But i want to set ciphersuite in SSLConnection using HttpsURLConnection. Under this class (HttpsURLConnection) there is no such method where u can specify the ciphersuite.
    So i am trying to find out when an SSL connection is setup from where does the JVM loads the cipher suites? I checked the All the basic classes in javax.net.ssl package and all contain the methods as abstract. So if anybody has any idea regarding where these supported cipher suites are located in jdk please let me knw.
    Thanks in advance :)
    Arun

  • Why in Firefox there are no cipher suits with SHA-256?

    I don't see cipher suits with SHA-256 in Firefox ClientHello. Why? They are not supported?

    I think that it is best to keep the discussion in one thread, so I locking the other two that you created.
    Please continue here: [[/questions/976999]]

  • TLS fails - no cipher suites in common

    When I enable TLS on the instant messaging server, I can't connect to it using TLS. I am using a self signed cert. Do I need to put the certificate authority in the JKS?
    steve
    Version
    [15 Apr 2010 13:46:00,927] INFO xmppd [main] Starting XMPP Server: Version 8.0
    Patch: 139893-02
    iim.conf
    ! tls configuration
    iim_server.sslkeystore=/etc/opt/SUNWiim/default/config/im.jks
    iim_server.keystorepasswordfile=/etc/opt/SUNWiim/default/config/sslpassword.conf
    iim_server.requiressl=false
    iim_server.trust_all_cert=true
    iim_server.certnickname=im.uwo.ca
    # keytool -list -V -keystore im.jks
    Enter keystore password: Mu51cdi3
    Keystore type: jks
    Keystore provider: SUN
    Your keystore contains 1 entry
    Alias name: im.uwo.ca
    Creation date: Apr 15, 2010
    Entry type: trustedCertEntry
    Owner: [email protected], CN=im.uwo.ca, OU=ITS, O=The University of Western Ontario, L=London, ST=Ontario, C=CA
    Issuer: [email protected], CN=UWO Certificate Authority, OU=Information Technology Services, O=The University of Western Ontario, L=London, ST=Ontario, C=CA
    Serial number: 13a
    Valid from: Thu Apr 15 09:05:42 EDT 2010 until: Fri Apr 15 09:05:42 EDT 2011
    Certificate fingerprints:
    MD5: FB:21:99:37:29:45:8C:B6:B1:55:0B:61:5B:93:28:FE
    SHA1: 4D:3B:24:72:D5:CB:2D:AA:D7:7F:6B:E6:3B:F1:DB:31:5F:64:FB:6B
    [15 Apr 2010 13:46:55,767] DEBUG xmppd [default-iim_server-worker 2] last read count 51
    [15 Apr 2010 13:46:55,770] DEBUG xmppd.xfer [default-iim_server-worker 2] [null] Received:<starttls xmlns='urn:ietf:par
    ams:xml:ns:xmpp-tls' xml:lang='en'/>
    [15 Apr 2010 13:46:55,770] DEBUG xmppd [default-iim_server-worker 2] [ClientPacketDispatcher] StartTLS Packet detected
    [15 Apr 2010 13:46:55,771] DEBUG xmppd [default-iim_server-worker 2] Session[null] Starting TLS nego : false, null
    [15 Apr 2010 13:46:55,776] DEBUG xmppd [default-iim_server-worker 2] [SecureByteChannel] TLS started for channel id : 2
    com.iplanet.im.server.io.MuxChannel@107108e
    [15 Apr 2010 13:46:55,776] DEBUG xmppd [default-iim_server-worker 2] last read count 0
    [15 Apr 2010 13:46:55,776] DEBUG xmppd [default-iim_server-worker 2] Session[null] processed input
    [15 Apr 2010 13:46:55,776] DEBUG xmppd [default-iim_server-worker 2] ConnectedStreamEndPoint finished process()
    [15 Apr 2010 13:46:55,777] DEBUG xmppd [default-iim_server-worker 2] ConnectedStreamEndPoint started process()
    [15 Apr 2010 13:46:55,777] DEBUG xmppd [default-iim_server-worker 2] ConnectedStreamEndPoint[null] processing input
    [15 Apr 2010 13:46:55,777] DEBUG xmppd [default-iim_server-worker 2] last read count 0
    [15 Apr 2010 13:46:55,777] DEBUG xmppd [default-iim_server-worker 2] Session[null] processed input
    [15 Apr 2010 13:46:55,777] DEBUG xmppd [default-iim_server-worker 2] ConnectedStreamEndPoint finished process()
    [15 Apr 2010 13:46:55,782] DEBUG xmppd [default-iim_server-worker 0] ConnectedStreamEndPoint started process()
    [15 Apr 2010 13:46:55,782] DEBUG xmppd [default-iim_server-worker 0] ConnectedStreamEndPoint[null] processing input
    [15 Apr 2010 13:46:55,782] DEBUG xmppd [default-iim_server-worker 0] last read count 90
    [15 Apr 2010 13:46:55,783] DEBUG xmppd [default-iim_server-worker 0] Session[null] processed input
    [15 Apr 2010 13:46:55,784] DEBUG xmppd [default-iim_server-worker 0] ConnectedStreamEndPoint finished process()
    [15 Apr 2010 13:46:55,784] DEBUG xmppd [default-iim_server-worker 0] ConnectedStreamEndPoint started process()
    [15 Apr 2010 13:46:55,784] DEBUG xmppd [default-iim_server-worker 0] ConnectedStreamEndPoint[null] processing input
    [15 Apr 2010 13:46:55,784] DEBUG xmppd [default-iim_server-worker 0] last read count 0
    [15 Apr 2010 13:46:55,789] DEBUG xmppd [default-iim_server-worker 2] sslEngine closed
    java.io.EOFException: sslEngine closed
    at com.iplanet.im.common.ssl.SecureServerByteChannel.handleResult(SecureServerByteChannel.java:338)
    at com.iplanet.im.common.ssl.SecureServerByteChannel.write(SecureServerByteChannel.java:244)
    at com.iplanet.im.common.ssl.SecureServerByteChannel.handleHandshakeResult(SecureServerByteChannel.java:404)
    at com.iplanet.im.common.ssl.SecureServerByteChannel.access$300(SecureServerByteChannel.java:27)
    at com.iplanet.im.common.ssl.SecureServerByteChannel$2.run(SecureServerByteChannel.java:391)
    at org.netbeans.lib.collab.util.Worker.run(Worker.java:244)
    at java.lang.Thread.run(Thread.java:619)
    [15 Apr 2010 13:46:55,792] DEBUG xmppd [default-iim_server-worker 2] [hsep]removing xmlns from packet ...
    [15 Apr 2010 13:46:55,793] DEBUG xmppd [default-iim_server-worker 0] Sending CMD_CLOSE for channel: 2
    [15 Apr 2010 13:46:55,793] INFO xmppd [default-iim_server-worker 0] MuxChannel.close() Server Closing client for chann
    el : 2,null
    [15 Apr 2010 13:46:55,794] DEBUG xmppd [default-iim_server-worker 0] Session[null] outbound status changed from opened
    to disconnected
    [15 Apr 2010 13:46:55,794] DEBUG xmppd [default-iim_server-worker 0] Session[null] inbound status changed from opened t
    o disconnected
    [15 Apr 2010 13:46:55,794] INFO xmppd [default-iim_server-worker 0] session.close() nullcloseStream false
    [15 Apr 2010 13:46:55,794] DEBUG xmppd [default-iim_server-worker 0] [CSEP]null closeImpl
    [15 Apr 2010 13:46:55,794] DEBUG xmppd [default-iim_server-worker 0] [CSEP] null closeSASLProvider
    [15 Apr 2010 13:46:55,794] DEBUG xmppd [default-iim_server-worker 0] Session[null] closed
    [15 Apr 2010 13:46:55,794] DEBUG xmppd [default-iim_server-worker 0] Removed connectionId : gz5im1.its.uwo.pri:7, this
    : jid : nullcom.iplanet.im.server.ConnectedStreamEndPoint@1198ff2 , jid : null
    [15 Apr 2010 13:46:55,794] DEBUG xmppd [default-iim_server-worker 0] Session[null] leaveAllGroupChats
    [15 Apr 2010 13:46:55,795] DEBUG xmppd [default-iim_server-worker 0] RouterEndPoint[null [18452466]] removed all listen
    ers. STAT:numEndPointListener=0
    [15 Apr 2010 13:46:55,795] DEBUG xmppd [default-iim_server-worker 0] no cipher suites in common
    org.jabberstudio.jso.StreamException: no cipher suites in common
    at net.outer_planes.jso.AbstractStream.process(AbstractStream.java:1179)
    at com.iplanet.im.server.ConnectedStreamEndPoint.process(ConnectedStreamEndPoint.java:356)
    at com.iplanet.im.server.ConnectedStreamEndPoint.dataAvailable(ConnectedStreamEndPoint.java:312)
    at com.iplanet.im.server.io.MuxChannel$MuxReadRunnable.run(MuxChannel.java:452)
    at org.netbeans.lib.collab.util.Worker.run(Worker.java:244)
    at java.lang.Thread.run(Thread.java:619)
    [15 Apr 2010 13:46:55,797] DEBUG xmppd [default-iim_server-worker 0] ConnectedStreamEndPoint finished process()

    [email protected] wrote:
    When I enable TLS on the instant messaging server, I can't connect to it using TLS.What client are you using to connect to the IM Server and what platform is it running on?
    I am using a self signed cert. Do I need to put the certificate authority in the JKS? Not as far as I can tell.
    I used the self-signed cert from Messaging Server (./msgcert generate-certDB) and the steps provided at http://forums.sun.com/thread.jspa?messageID=10971294#10971294 and TLS worked fine with the same version as you are running.
    I was testing with Pidgin 2.6.2 on Ubuntu 9.10.
    Do you see:
    [16 Apr 2010 16:13:03,421] INFO  xmppd [main] SSL initialized - using JKSThe keytool output from my test system is below:
    bash-3.00# keytool -list -V -keystore server-keystore.jks
    Enter keystore password:  password
    Keystore type: jks
    Keystore provider: SUN
    Your keystore contains 1 entry
    Alias name: server-cert
    Creation date: 16/04/2010
    Entry type: keyEntry
    Certificate chain length: 1
    Certificate[1]:
    Owner: CN=mumble.aus.sun.com
    Issuer: CN=mumble.aus.sun.com
    Serial number: 90509a40
    Valid from: Wed Mar 24 16:01:17 EST 2010 until: Thu Jun 24 15:01:17 EST 2010
    Certificate fingerprints:
             MD5:  8C:8D:67:03:2C:4C:64:B6:73:45:94:36:FA:D6:CE:4C
             SHA1: B8:3E:F3:F0:D9:0C:B9:16:2F:82:3A:22:C6:1D:62:B3:90:18:02:34
    *******************************************Regards,
    Shane.

  • No Cipher suites in common

    Hello,
    When I switch to using "setNeedClientAuth" to true on the end of the server the socket fails to connect. The error message that I get is "fatal handshake failure, no cipher suites in common". When I do not require client authentication, the program runs fine.
    I created my own key using the RSA algorithem (as specified in other postings) using keytool. This does not help.
    I've noticed that alot of the posts related to this don't seem to get answered.
    If I cannot get client authentication to work correctly, then this security extension is worthless to me.
    Dan Hughes

    Hello, i saw you had the same problem that I'm having right now about the handshake exception "No Cipher suites in common".Could you fix this??
    Thanks a lot.
    This was your post:
    When I switch to using "setNeedClientAuth" to true
    e on the end of the server the socket fails to
    connect. The error message that I get is "fatal
    handshake failure, no cipher suites in common". When
    I do not require client authentication, the program
    runs fine.
    I created my own key using the RSA algorithem (as
    specified in other postings) using keytool. This does
    not help.
    I've noticed that alot of the posts related to this
    don't seem to get answered.
    If I cannot get client authentication to work
    correctly, then this security extension is worthless
    to me.

  • Help enabling AES 256-bit cipher suites

    I can't seem to create an SSLServerSocket with the 2 AES 256-bit cipher suites that are supposed to be available in JDK1.4.2. As you can see in the following code, the SSLServerSocket, ss, is enabled with the 2 AES_256 cipher suites. But, when ss.getEnabledCipherSuites() is invoked, those 2 suites aren't listed. What's up?
    Also, what is this SSLv2Hello that I can't seem to get rid of?
        String[] PROTOCOLS = {"SSLv3", "TLSv1"};
        String[] CIPHER_SUITES = {"TLS_DHE_RSA_WITH_AES_256_CBC_SHA",
                                  "TLS_DHE_RSA_WITH_AES_128_CBC_SHA",
                                  "SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA",
                                  "TLS_RSA_WITH_AES_256_CBC_SHA",
                                  "TLS_RSA_WITH_AES_128_CBC_SHA",
                                  "SSL_RSA_WITH_3DES_EDE_CBC_SHA"};// create an SSLServerSocket ss
            SSLContext context = SSLContext.getInstance("TLS", "SunJSSE");
            context.init(myKeyManagers, myTrustManagers, SecureRandom.getInstance("SHA1PRNG", "SUN"));
            SSLServerSocketFactory ssFactory = context.getServerSocketFactory();
            SSLServerSocket ss = ssFactory.createServerSocket();
            ss.setEnabledProtocols(PROTOCOLS);
            ss.setEnabledCipherSuites(CIPHER_SUITES);// output a bunch of useful debugging information
            System.out.println(System.getProperty("java.version") + "\n");
            Provider[] providers = Security.getProviders();
            for(int i=0; i < providers.length; ++i)
                System.out.println(providers[i] + "\n" + providers.getInfo() + "\n********************");
    String[] enabledProtocols = ss.getEnabledProtocols();
    for(int i=0; i < enabledProtocols.length; ++i)
    System.out.println(enabledProtocols[i]);
    String[] enabledCipherSuites = ss.getEnabledCipherSuites();
    for(int i=0; i < enabledCipherSuites.length; ++i)
    System.out.println(enabledCipherSuites[i]);
    OUTPUT
    1.4.2
    SUN version 1.42
    SUN (DSA key/parameter generation; DSA signing; SHA-1, MD5 digests; SecureRandom; X.509 certificates; JKS keystore; PKIX CertPathValidator; PKIX CertPathBuilder; LDAP, Collection CertStores)
    SunJSSE version 1.42
    Sun JSSE provider(implements RSA Signatures, PKCS12, SunX509 key/trust factories, SSLv3, TLSv1)
    SunRsaSign version 1.42
    SUN's provider for RSA signatures
    SunJCE version 1.42
    SunJCE Provider (implements DES, Triple DES, AES, Blowfish, PBE, Diffie-Hellman, HMAC-MD5, HMAC-SHA1)
    SunJGSS version 1.0
    Sun (Kerberos v5)
    SSLv2Hello
    SSLv3
    TLSv1
    TLS_DHE_RSA_WITH_AES_128_CBC_SHA
    SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
    TLS_RSA_WITH_AES_128_CBC_SHA

    Now I get an Exception when I run the same program.
    OUTPUT
    1.4.2
    SUN version 1.42
    SUN (DSA key/parameter generation; DSA signing; SHA-1, MD5 digests; SecureRandom; X.509 certificates; JKS keystore; PKIX CertPathValidator; PKIX CertPathBuilder; LDAP, Collection CertStores)
    SunJSSE version 1.42
    Sun JSSE provider(implements RSA Signatures, PKCS12, SunX509 key/trust factories, SSLv3, TLSv1)
    SunRsaSign version 1.42
    SUN's provider for RSA signatures
    SunJCE version 1.42
    SunJCE Provider (implements DES, Triple DES, AES, Blowfish, PBE, Diffie-Hellman, HMAC-MD5, HMAC-SHA1)
    SunJGSS version 1.0
    Sun (Kerberos v5)
    java.lang.IllegalArgumentException: Cannot support TLS_DHE_RSA_WITH_AES_256_CBC_SHA with currently installed providers
            at com.sun.net.ssl.internal.ssl.CipherSuiteList.<init>(DashoA6275)
            at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.setEnabledCipherSuites(DashoA6275)
            at test.util.ConcreteSSLServerSocketFactory.initSocket(ConcreteSSLServerSocketFactory.java:111)
            at test.util.ConcreteSSLServerSocketFactory.createServerSocket(ConcreteSSLServerSocketFactory.java:100)
            at test.Test.main(Test.java:111)
    Exception in thread "main"

  • Schannel cipher suites and ChaCha20

    Is there a blog or other communications channel devoted to the PKI internals of Windows? Most security researchers focus on Linux web servers/OpenSSL, but there are folks in the Windows world who really care about this stuff too, and we'd like to hear
    about what the Windows PKI developers are working on and planning, and perhaps interact with comments and suggestions.
    Because I couldn't find any discussion about Schannel development, I started a
    feature suggestion on the Windows User Voice site for Microsoft to add ChaCha20-Poly1305 cipher suites to Schannel, mostly for the benefit of mobile visitors to IIS websites, but also to help Windows phones and tablets that don't have integrated CPU extensions
    for GCM encryption (improved speed and reduced power consumption).
    It's frustrating to be a security-focused IIS website administrator. Schannel is a "black box" that we can't tinker with or extend ourselves, and support for modern ciphers has been lagging behind other website and client software (it looks like we'll
    at least finally get strong and forward secret ECDHE_RSA + AES + GCM suites with Windows 10 and Server vNext/2016). The methods for configuring cipher suite orders and TLS versions could really use a rethink too (thank goodness for IISCrypto).

    Hi Jamie_E,
    May the following article can help you,
    Cipher Suites in Schannel
    http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757%28v=vs.85%29.aspx
    Managing SSL for a Client Access Server
    http://technet.microsoft.com/en-us/library/bb310795.aspx
    Configuring Secure Sockets Layer in IIS 7
    http://technet.microsoft.com/en-us/library/cc771438(WS.10).aspx
    How to enable Schannel event logging in IIS
    https://vkbexternal.partners.extranet.microsoft.com/VKBWeb/?portalId=1#
    How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll
    http://support.microsoft.com/kb/245030/EN-US
    I’m glad to be of help to you!
    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact [email protected]

Maybe you are looking for