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

Similar Messages

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

SSL Medium Strength Cipher Suites Supported vulnerability

Kind of an odd thing. We just had a vulnerability scan and a 2960 got pinged for supporting medium strength SSL cipher suites. I say strange cause I have 3 others that have the same IOS image and they didn't get pinged. Swap out the management IP address and they are all the same. They are all running 12.2(52)SE C2960-LANBASEK9-M, with a 768 bit keys. Here is the text of the vulnerability :
Synopsis : The remote service supports the use of medium strength SSL ciphers. Description : The remote host supports the use of SSL ciphers that offer medium strength encryption, which we currently regard as those with key lengths at least 56 bits and less than 112 bits.
Reconfigure the affected application if possible to avoid use of medium strength ciphers. / CVSS Base Score : 5.0 (CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N) Plugin output : Here are the medium strength SSL ciphers supported by the remote server : Medium Strength Ciphers (>= 56-bit and < 112-bit key) SSLv3 EDH-RSA-DES-CBC-SHA Kx=DH Au=RSA Enc=DES(56) Mac=SHA1 DES-CBC-SHA Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1 TLSv1 EDH-RSA-DES-CBC-SHA Kx=DH Au=RSA Enc=DES(56) Mac=SHA1 DES-CBC-SHA Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1 The fields above are : {OpenSSL ciphername} Kx={key exchange} Au={authentication} Enc={symmetric encryption method} Mac={message authentication code} {export flag}
Can someone point me in the right direction on how to re-configure the switch to pass this test?
Thanks
Poirot

I believe the alert there is because you are using a 768 key which was broken recently (Jan 2010 a paper was published on it with results from efforts that took 4 years to break 768 keys). 768bit RSA keys is not considered secure enough any more.
I would suggest you to configure keys of 1024 on these switches and try again.
I hope it helps.
PK

Supported Cipher suites.

Hi All,
I am successfully communicating with the server using HTTPS with HttpsConnection from my J2ME Midlet. I am using APACHE as HTTP Server. However, the best cipher suite negutiated between the device and the server used by HTTPS was DES-CBC3-SHA. As you can see, it uses DES, which is not quite as secure as AES.However despite a lot of effort, i am just not able to get it to use an AES cipher suite. Is AES part of any supported cipher suite by MIDP? If not, can anyone tell me how i can enumeration the cipher suites supported on the MIDLet?
Thanks in advance
Edited by: AUTOMATON on Sep 14, 2007 3:38 AM

@superena,
Thanks for the links, but they actually dont give me the info I need. What I want to do is to find out how many SSL cipher suites are supported by J2ME. I mean if there is a list somewhere, of if i can write a program that can enumerate them for me..

OEM weak cipher support

Hello,
If a box running Oracle is scanned with a vulnerability scanner it finds many vulnerabilities of weak SSL ciphers supported.
TCP:1158 - DES-CBC-SHA (SSLv3) - SSL Weak Cipher Supported
TCP:1158 - DES-CBC-SHA (TLSv1) - SSL Weak Cipher Supported
TCP:1158 - EDH-RSA-DES-CBC-SHA (SSLv3) - SSL Weak Cipher Supported
TCP:1158 - EDH-RSA-DES-CBC-SHA (TLSv1) - SSL Weak Cipher Supported
TCP:1158 - EXP-DES-CBC-SHA (SSLv3) - SSL Weak Cipher Supported
TCP:1158 - EXP-DES-CBC-SHA (TLSv1) - SSL Weak Cipher Supported
TCP:1158 - EXP-EDH-RSA-DES-CBC-SHA (SSLv3) - SSL Weak Cipher Supported
TCP:1158 - EXP-EDH-RSA-DES-CBC-SHA (TLSv1) - SSL Weak Cipher Supported
TCP:1158 - EXP-RC4-MD5 (SSLv3) - SSL Weak Cipher Supported
TCP:1158 - EXP-RC4-MD5 (TLSv1) - SSL Weak Cipher Supported
TCP:1158 - DES-CBC-SHA (SSLv3) - SSL Weak Cipher Strength Supported
TCP:1158 - DES-CBC-SHA (TLSv1) - SSL Weak Cipher Strength Supported
TCP:1158 - EDH-RSA-DES-CBC-SHA (SSLv3) - SSL Weak Cipher Strength Supported
TCP:1158 - EDH-RSA-DES-CBC-SHA (TLSv1) - SSL Weak Cipher Strength Supported
TCP:1158 - EXP-DES-CBC-SHA (SSLv3) - SSL Weak Cipher Strength Supported
TCP:1158 - EXP-DES-CBC-SHA (TLSv1) - SSL Weak Cipher Strength Supported
TCP:1158 - EXP-EDH-RSA-DES-CBC-SHA (SSLv3) - SSL Weak Cipher Strength Supported
TCP:1158 - EXP-EDH-RSA-DES-CBC-SHA (TLSv1) - SSL Weak Cipher Strength Supported
TCP:1158 - EXP-RC4-MD5 (SSLv3) - SSL Weak Cipher Strength Supported
TCP:1158 - EXP-RC4-MD5 (TLSv1) - SSL Weak Cipher Strength Supported
TCP:1158 - (512) - SSL Certificate Weak Public Key Strength
How can I lock down the local OEM to only TLS high ciphers?
Thanks
Matt

I think that this was included as a reference in the doc that Eric had linked.
-- Restricting access to console with https only
$OMS_HOME/bin/emctl stop oms
$OMS_HOME/bin/emctl secure lock -console
$OMS_HOME/bin/emctl start oms
-- Forcing the protocol to be TLSv1 only
$OMS_HOME/bin/emctl stop oms
$OMS_HOME/bin/emctl secure oms -protocol TLSv1
cd /oracle/gc_inst/user_projects/domains/GCDomain/bin
cp startEMServer.sh startEMServer.sh_backup
vi startEMServer.sh
-- add this option to JAVA_OPTIONS line in the file
-Dweblogic.security.SSL.protocolVersion=TLS1
$OMS_HOME/bin/emctl start oms
-- Recreate the certificate with higher key strength
$OMS_HOME/bin/emctl secure createca -sysman_pwd your_sysman_password -key_strength 1024 -cert_validity 3650
I included a couple of additional steps. We are also having to implement additional security to grid control. We are still working through issues with creating a new certificate with support. After that is resolved, then we need to re-secure our agents to run on the newly created certificate & require them to use the stronger protocol. I will post the steps that we use once everything is done.
I also included a link to a couple of the docs that assisted us.
HTH,
Brian
Oracle® Enterprise Manager Administration 11g Release 1 (11.1.0.1)
2 Enterprise Manager Security
http://download.oracle.com/docs/cd/E11857_01/em.111/e16790/security3.htm#BABJGJAA
Oracle Enterprise Manager Grid Control 11gRelease 1 Security Deployment–BestPractices
http://www.oracle.com/technetwork/oem/grid-control/twp-security-best-practices-133704.pdf

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?

SSL Weak Cipher

We have a new security product that has detected SSL Weak Cipher strengths. I have been going round and round trying to figure out what the issue might be.
What I am down to is a config option with the OpenSSL. It appears it reads the SSL Cipher strengths from the vhost-ssl.conf file in the \etc\apache2\vhosts.d directory.
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSL v2:+EXP:+eNULL
The above is the default string. I have changed it as follows to eliminate the weak SSLv2.
SSLCipherSuite ALL:!ADH:!EXport56:RC4+RSA:+HIGH:+MEDIUM:+SSLv3:+E XP:+eNULL:-SSLv2
The problem is the server still comes back support encryption less than 128 bit. What options do I need to change to fix this issue?

IS this an OES1 or OES2 server? On what port is the weak cipher being used? When you installed your server, did you enable the option to use certificates from eDirectory?

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.

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

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]

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.

Weak cipher suites supported on WCS port 8082

Similar Messages

Maybe you are looking for