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]

Similar Messages

How to specify a cipher suit used between plugin and weblogic server?

I install Weblogic8.1 SP3 which supports for strong cipher suits, and config an apache 2.50 server as an front end.
I config appache to use 2 way SSL with browser and wls one way SSL with apache plugin. Then config apache to forward client certs to WLS. now the problem is, I can see that the SSL connection between browser and apache uses a strong cipher suit('SSL_RSA_WITH_RC4_128_MD5'), but the ssl connection bwtween apache plugin and WLS uses a weak cipher suit('SSL_RSA_EXPORT_WITH_RC4_40_MD5'), with the SnoopServlet, although I use the mod_wl128_20.so module. How can I increase the cipher strength of SSL between WLS and it's apache plugin?
Thanks in advance.
Best
Regards
Jean

Hello Gunaseelan,
This is not possible because WLS 6.1 needs a config.xml file, exactly this
name, to start.
What you can do is to define a recovery domain, called myrecovery_domain for
instance, and put the config_recovery.xml, renamed "config.xml".
Hope this helps,
Ludovic.
Developer Relations Engineer
BEA Support.
"Gunaseelan Venkateswaran" <[email protected]> a écrit dans le message
news: 3cd6a324$[email protected]..
>
Hi,
I have 2 weblogic startup scripts (startWebLogic.sh and
startWebLogic_recovery.sh) for the same domain.
startWebLogic.sh uses config.xml file.
I would like to use config_recovery.xml as the configuration file forstartWebLogic_recovery.sh
>
>
How would I do this ?
I am using WebLogic Server 6.1 on SunOS 5.8 / HP-UX 11.0.
Appreciate any help.
Regards
Gunaseelan Venkateswaran

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?

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

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

SSL and TLS Cipher Suites

Hello,
I am tying to use the SSLContext class in a nonblocking IO application with "TLS" protocol in Server mode.
I am seeing a "no cipher suites in common" error message during the handshake.
The Client is requesting for "TLS_RSA_WITH_RC4_128_MD5" but this cipher is not available (verified from the list returned by SSLEngine.getSupportedCipherSuites()).
I have the following questions.
1> Are SSL_RSA_WITH_RC4_128_MD5 and TLS_RSA_WITH_RC4_128_MD5 the same?
2>Is it possible for me to register TLS_RSA_WITH_RC4_128_MD5 as an alias for SSL_RSA_WITH_RC4_128_MD5?
3> How can I get the Server to recognize TLS_RSA_WITH_RC4_128_MD5?
Thanks,
arun.

Hello,
I am tying to use the SSLContext class in
a nonblocking IO application with "TLS" protocol in
Server mode.
I am seeing a "no cipher suites in common" error
message during the handshake.
The Client is requesting for
"TLS_RSA_WITH_RC4_128_MD5" but this cipher is not
available (verified from the list returned by
SSLEngine.getSupportedCipherSuites()).
I have the following questions.
1> Are SSL_RSA_WITH_RC4_128_MD5 and
TLS_RSA_WITH_RC4_128_MD5 the same?Yes
2>Is it possible for me to register
TLS_RSA_WITH_RC4_128_MD5 as an alias for
SSL_RSA_WITH_RC4_128_MD5?Shouldn't be necessary, as they are compared by RFC2246 value, not by name.
3> How can I get the Server to recognize
TLS_RSA_WITH_RC4_128_MD5?Do the client and server both create their SSLContexts with "TLS". Do either of them modify the enabled cipher suites? Does the server have an RSA certificate?

Schannel Errors 36874 and 36888

Greetings,
The scenario is the following: 1 Windows Server 2008 R2 SP1 (patched up to date).
There are two errors that shows every 10 seconds:
Log Name:      System
Source:        Schannel
Date:          19/07/2012 14:59:58
Event ID:      36874
Task Category: None
Level:         Error
Keywords:
User:          SYSTEM
Computer:      Server.Mydomain.com
Description:
An SSL 3.0 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
    <Provider Name="Schannel" Guid="{1F678132-5938-4686-9FDC-C8FF68F15C85}" />
    <EventID>36874</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000000000000000</Keywords>
    <TimeCreated SystemTime="2012-07-19T19:59:58.511146300Z" />
    <EventRecordID>5908</EventRecordID>
    <Correlation />
    <Execution ProcessID="484" ThreadID="524" />
    <Channel>System</Channel>
    <Computer>Server.Mydomain.com</Computer>
    <Security UserID="S-1-5-18" />
</System>
<EventData>
    <Data Name="Protocol">SSL 3.0</Data>
</EventData>
</Event>
Log Name:      System
Source:        Schannel
Date:          19/07/2012 14:59:58
Event ID:      36888
Task Category: None
Level:         Error
Keywords:
User:          SYSTEM
Computer:      Server.Mydomain.com
Description:
The following fatal alert was generated: 40. The internal error state is 107.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
    <Provider Name="Schannel" Guid="{1F678132-5938-4686-9FDC-C8FF68F15C85}" />
    <EventID>36888</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000000000000000</Keywords>
    <TimeCreated SystemTime="2012-07-19T19:59:58.511146300Z" />
    <EventRecordID>5909</EventRecordID>
    <Correlation />
    <Execution ProcessID="484" ThreadID="524" />
    <Channel>System</Channel>
    <Computer>Server.Mydomain.com</Computer>
    <Security UserID="S-1-5-18" />
</System>
<EventData>
    <Data Name="AlertDesc">40</Data>
    <Data Name="ErrorState">107</Data>
</EventData>
</Event>
Note: This server has IIS installed (requirement for web console of System Center Operations Manager 2012)
The questions are:
Is this behavior normal?
if no
How to fix this problem?
Thanks in advance!

Hi,
This error can be received due to an incompatible browser problem and SSL 3.0 connection request cannot be handled.
As discussed, we can modify that registry key to disable the additional secure channel event logging if every works fine.
Also we can check the thread below. It mentioned another scenario in which the "The following fatal alert was generated: 40. The internal error state is 107." error could be received:
Why does Window's SSL Cipher-Suite get restricted under certain SSL certificates?
http://serverfault.com/questions/166750/why-does-windows-ssl-cipher-suite-get-restricted-under-certain-ssl-certificates
(Note: Since the site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.)
Regards
Kevin

How to add a Cipher Suite using RSA 1024 algorithm to the 'SSL Cipher Suite Order' GPO

Following a VA test the Default Domain GPO has been set to enable the SSL Cipher Suite Order. Following the change Symantec Endpoint Protection Manager doesn't work properly as the the Home, Monitors and Reports pages are blank and an Schannel error is
logged in the SEPM server's event log.
I have spoken to Symantec and I have been told that we need to allow the RSA 1024 bit algorithm but they can't tell me which cipher suite this would be. I have looked in the GPO setting and can't see an RSA 1024 suite but have found some in this article:
http://tools.ietf.org/html/draft-ietf-tls-56-bit-ciphersuites-01
I want to know how to add an additional cipher suite into the setting safely. Am I able to just add the suite into the GPO setting (eg TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA) or do I need to do anything else beforehand?
If anyone has any advice regarding this or cipher suite orders and troubleshooting SSL problems it would be much appreciated,
Thanks
Chris

Hi Chris,
Based on my research, RSA_EXPORT1024_DES_CBC_SHA is a previous cipher suite, which is supported, you can enable it use
SSL Cipher Suite Order policy setting under Administrative Templates\Network\SSL Configuration Settings.
More information for you:
TLS/SSL Cryptographic Enhancements
http://technet.microsoft.com/en-us/library/cc766285(v=WS.10).aspx
Best Regards,
Amy

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);

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

What is the Chiper suite and TLS and SSL protocol sent by safari browser ver 8 from iOS8

Hello,
I have a production environment where users login in from Ipad/Iphone having Ios8 and safari v8 are not able to log on to the application.
However, on the same Ipad/Iphone when user tries login in with Chrome or any other browser , they are able to login.
I need the following help/information:
1. What is the SSL/TLS protocol version that is supported or used by Apple iOS8.
2. What is the cipher suites of safari version 8
Any information on this would be very helpful.
Thanks,
Parin.

Just to recap, this is a collection of ports I have collected over time for people who needed this information when setting up the HP ePrint app so that they could view their email from within the app. I am certain other applications also need this information. Although lengthy, I could not find a more comprehensive place to retrieve this information. Feel free to post additional information, faulty information, or other related topics below as this is simply a collection of data and it would be practically impossible to test all of them. Thank you!
Don't forgot to say thanks by giving "Kudos" if I helped solve your problem.
When a solution is found please mark the post that solves your issue.
Every problem has a solution!

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.

TLS cipher suites: Is there any Windows application that is using one of the two NULL cipher suites?

My question is about these two standard cipher suites from Windows 7/8 (and Windows Servers):
TLS_RSA_WITH_NULL_SHA256
TLS_RSA_WITH_NULL_SHA
Question: Is there any native Windows 7 application/process that must use one of these two ciphers?
If not, I would simply kick them out to make sure that they are never used.
Bonus question: Is there any reason to keep these on any Windows Server?

Thank you for your response. I kicked out the NULL ciphers and everything weaker than 3DES. Consequently I also deactivated SSLv3 on five windows clients (computers and not servers, no server admin here). Rearranged the order of preference according to
my needs. So far I don't experience any issues. Did the same with JRE many years ago (just kicked it out), now I lean back and enjoy the show.

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

Weak cipher suites supported on WCS port 8082

Hi
Port 8082 is used for health monitoring in WCS, a web service is running on this port so we can login via web and check the status.
I would like to know, is there a way to limit the cipher suite supported on this port? For port 443, this can be done by modify the Apache configuration file, however this doesn't work for 8082. The version is 5.2.148.0.
Thanks and Regars,
Leo

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 ***

Schannel cipher suites and ChaCha20

Similar Messages

Maybe you are looking for