We are running an asp.net application in IIS 10.0 (windows server 2016) and installed SSL certificate. One of our clients was asking us about supporting TLS 1.3. My understanding is that TLS 1.3 is still in draft and I found no reference for server 2016 and TLS 1.3. What can we do to provide support for TLS 1.3 (other than waiting for this version to be officially released)?
Would it be correct to say that we will support TLS 1.3 when Server 2016 begins to support it?
This is old, but I think it deserves an update at this point. TLS 1.3 has been finalized for over a year now. It's no longer in a draft as of 8/2018 and is finalized and published. Yet still, no support from MS. This is extremely poor on their part. All the ciphers in TLS 1.2 and lower have been compromised or are vulnerable to attack - such as timing-based attacks. Only TLS 1.3 AEAD based ciphers are - as of this time - uncompromised or not known to be vulnerable.
Come on MS. It's been almost 1.5 years. I thought you were serious about security!!! You talk the talk - now walk the walk and get us TLS 1.3 support!!!
Related
I'm getting this error message while using the "Test connection to your bot" section on https://dev.botframework.com/.
An error occurred while sending the request. The request was aborted: Could not create SSL/TLS secure channel.
As noted in this Stack Overflow question, the bot framework does not work with self-signed certs.
However, this is not a self-signed cert. It is issued by DigiCert and my browser does not complain about it.
The endpoint is https://gem-hair.hyperdev.space/chat
EDIT: per http://social.technet.microsoft.com/wiki/contents/articles/31634.microsoft-trusted-root-certificate-program-participants-v-2016-april.aspx, DigiCert is a trusted certificate root.
One of my colleague took a look. It seems that your cert requires TLS 1.2 which we don't currently support. We are working on a fix.
We do currently support TLS 1.0.
EDIT: Some clarifications. My earlier statement above about your cert is wrong. It's not your cert that requires TLS 1.2.
BotFramework endpoints supports TLS 1.0, 1.1 and 1.2 on connections inbound to it. However connections outbound from it was configured only for SSLv3 and TLS 1.0. Your "gem-hair" endpoint in Amazon EC2 is configured to only accept incoming connections with TLS 1.1 and 1.2. You can check this using https://ssllabs.com. That's why BotFramework can't reach you.
UPDATE: We updated outbound support to TLS 1.0, 1.1 and 1.2. This problem is now fixed.
I am not an expert on EWS or TLS 1.2. And I am not sure on how to investigate on this issue.
Basically, I have client application that is heavily using EWS, in a form of pulling data from Exchange server and receiving notifications on subscribed topics from Exchange server.
I have a question from client that I am working for. Does EWS connection, that I use from client app to Exchange server supports TLS 1.2?
Exchange servers can be both 2010 and 2013.
I am not sure how I can confirm this, or this is supported by default.
Any advices or suggestions are welcome.
EDIT:
Client application is written in JavaScript.
The endpoint for Exchange server is https://outlook.office365.com/EWS/Exchange.asmx
As obvious it is https endpoint. Does this means that is is already working well under TLS 1.2 compliance?
TLS is done at the transport layer so for EWS the support depends on the underlying IIS setting. For Office365, the answer is yes (see here).
HTTPS (OWA, Outlook, EWS, Remote PS, etc.) – The support for TLS 1.1 and 1.2 is based on the support in IIS itself. Windows 2008 R2 or later supports both TLS 1.1 and 1.2, though the specific version of Windows may have these disabled or enabled by default. There is another important caveat here: the HTTPS proxy between CAS and Mailbox requires TLS 1.0 in current versions of Exchange Server – so disabling TLS 1.0 between CAS and Mailbox causes the proxy to fail. This is also something we have addressed in the Exchange 2016 Preview. We hope to make this available in a future CU, or you can make a request for it via Support. If you have dedicated roles, you can technically disable TLS 1.0 between the client & CAS, but we still are not recommending this. Office 365 already supports TLS 1.1 & 1.2, if the client supports them.
Put basically the client endpoint support TLS 1.2 so as long as your client supports it you should be good.
Cheers
Glen
I have an HTTPS website and I want to reduce the SSL time of this website. The SSL certificate has been installed on AWS ELB.
If I access the site from Netherlands, the SSL Time is high but if I access the same site from other countries then the SSL time is low. Why is that?
I am basically trying to minimize the time which is showing in this page
http://tools.pingdom.com/fpt/#!/ed9oYJ/https://www.google.com/index.html
Many things influence the SSL time including:
Infrastructure (this won't affect just SSL but ALL network traffic):
Standard network issues (how far away your server is from client, how fast the network is in between... etc) as the SSL/TLS handshake takes several round trips. You have little control over these except changing hosting provider and/or using a CDN. AWS is, in my experience fast and you are only asking to improve SSL rather than general access times so maybe skip this one for now.
Server response time. Is the server under powered in CPU, Ram or disk? Are you sharing this host? Again general issue so maybe skip past this but SSL/TLS does take some processing power though, with modern servers it is barely noticeable nowadays.
Server OS. Newer is better. So if running Red Hat Linux 4 for example then expect it to be considerably slower than the latest Red Hat Linux 7, with improved networking stack and newer versions of key software like OpenSSL.
SSL set up (run your site through https://www.ssllabs.com/ssltest and you should get a state of health of this):
Ciphers used. There are older and slower ciphers and faster and new ones. Can get complicated here really quickly but generally you should be looking for ECDHE ciphers for most clients (and preferable ECDHE...GCM ones) and want to specify that server order should be used so you get to pick the cipher used rather than the client.
Certificate used. You'll want a RSA 2048 cert. Anything more is overkill and slow. Some sites (and some scanning tools) choose RSA 4096 certificates but these do have a noticeable impact on speed with no real increase in security (at this time - that may change). There are newer ECDSA certs (usually shown as 256 EC cert in ssllabs report) but these faster ECDSA certs are not supplied by all CAs and are not universally supported by all clients, so visitors on older hardware and software may not be able to connect with them. Apache (and very recently Nginx from v 1.11.0) supports dual certs to have best of both worlds but at the expense of having two certs and some complexity of setting them up.
Certificate Chain. You'll want a short certificate chain (ideal 3 cert long: your server, intermediary and the CAs root certificate). Your server should return everything but the last cert (which is already in browsers certificate store). If any of the chain is missing, some browsers will attempt to look the musing ones but this takes time.
Reliable cert provider. As well as shorter cert chains, better OCSP responders, their intermediaries also are usually cached in users browsers as they are likely to be used by other sites.
OCSP Stapling saves network trip to check cert is valid, using OCSP or CRL. Turning it on won't make a difference for Chrome as they don’t check for revocation (mostly but EV certificates do get checked). It can make a noticeable difference to IE so should be turned on if your server supports them but do be aware of some implementation issues - particularly nginx’s first Request after restart always fails when OCSP Stapling is turned on.
TLSv1.2 should be used and possibly TLSv1 .0 for older clients but no SSLv2 and SSLv3. TLSv1.1 is kind of pointless (pretty much everyone that supports that also supports the newer and better TLSv1.2). TLSv1.3 is currently being worked on and has some good performance improvements but has not been fully standardised yet as there are some known compatibility issues. Hopefully these will be resolved soon so it can be used. Note PCI compliance (if taking credit cards on your site) demands TLSv1.2 or above on new sites, and on all sites by 30th June 2018.
Repeat visits - while above will help with the initial connection, most sites require several resources to be downloaded and with bad set up can have to go through whole handshake each time (this should be obvious if you're seeing repeated SSL connection set ups for each request when running things like webpagetest.org):
HTTP Keep-Alives should be turned on so the connection is not dropped after each HTTP Request (this should be the default for HTTP/1.1 implementations).
SSL caching and tickets should be on in my opinion. Some disagree for some obscure security reasons that should be fixed in TLSv1.3 but for performance reasons they should be on. Sites with highly sensitive information may choose the more complete security over performance but in my opinion the security issues are quite complex to exploit, and the performance gain is noticeable.
HTTP/2 should be considered, as it only opens one connection (and hence only one SSL/TLS setup) and has other performance improvements.
I would really need to know your site to see which if above (if any) can be improved. If not willing to give that, then I suggest you run ssllabs test and ask for help with anything it raises you don't understand, as it can require a lot of detailed knowledge to understand.
I run a personal blog explaining some of these concepts in more detail if that helps: https://www.tunetheweb.com/security/https/
You can try ECDSA certificates: https://scotthelme.co.uk/ecdsa-certificates/
But the cost of https is only visible on the first requests: session tickets avoid that cost for all other requests. Are they activated? ( you can check it with ssllabs.com )
If you can you should use SPDY or http2, it may improve the speed too.
ECDSA keys, SPDY and http2 reduce the number of round trip necessary so it should reduce the difference between the two location.
You say that you're not using a CDN, but I believe you should be. Here's why:
Connecting via TLS/SSL involves handshaking a secure connection, and that requires extra communication between the client and server before any data can begin flowing. This link has a handy diagram of the SSL handshake, and this link explains the first few milliseconds of an HTTPS connection.
Jordan Sissel wrote about his experiences with SSL handshake latency:
I started investigating the latency differences for similar requests between HTTP and HTTPS.
...
It's all in the handshake.
...
The point is, no matter how fast your SSL accelerators (hardware loadbalancer, etc), if your SSL end points aren't near the user, then your first connect will be slow.
If you use a CDN, then the handshaking can be done between the client and the nearest edge location, dramatically improving the latency.
In order to protect Tibco BW from a POODLE attack, how can SSL v3.0 be disabled on its web server component (used in web services, http listener, etc) so that clients are only able to connect using TLS?
In your question you have not shared which version of TIBCO BusinessWorks you are using. However TIBCO has released hotfix patches to address the issue. The following is from the Release Notes of TIBCO Runtime Agent 5.9.0 Hotfix 4:
Closed Issues in 5.9.0_HF-004 (This Release)
TCRT-56
To protect from the POODLE SSLv3 vulnerability (CVE-2014-3566), the SSLv3
protocol is no longer supported for TLS/SSL connections. Only version 1.0
or higher of TLS is supported.
For backward compatibility with software that supports only SSLv3, you can
enable the SSLv3 protocol by setting the following system-wide properties
for client-side and server-side connections in the .tra file:
java.property.com.tibco.security.ssl.client.EnableSSLv3=true
java.property.com.tibco.security.ssl.server.EnableSSLv3=true
One of my legacy Ruby application still uses Ruby 1.8.7. It makes a lot of HTTP requests on third-party web services and some of them are over SSL.
Those third-party services are dropping their support of SSLv3 as of the POODLE vulnerability and I'd like to patch my clients to continue connecting to them.
Ruby's standard library Net::HTTP doesn't seem to have a way to change the SSL version used.
In Ruby's openssl (ssl-internal.rb) there is a way to change the version. Sadly, this is not exposed by Net::HTTP (https.rb).
Are we (users of Ruby 1.8.7) that screwed?
Edit : In fact, it seems that the client is switching to TLSv1 if the server doesn't support SSLv3. I have an SSL enabled website without SSLv3 support, behind Nginx, and I've verified that my 1.8.7 client is switching to TLSv1 and the request works. If you want to verify by yourself, take a look here : https://serverfault.com/questions/620123/how-can-i-let-nginx-log-the-used-ssl-tls-protocol-and-ciphersuite
In fact, it seems that the client is switching to TLSv1 if the server doesn't support SSLv3
It is more the other way around. Inside the SSL handshake the client shows to the server what it can (protocol, ciphers) and the server then picks from this the best it can too. Usually the client is just defaulting to SSLv23 which does not restrict the client itself to a specific protocol. If the server then offers TLSv1 they will continue with it, if the server only offers SSLv3 they will use SSL 3.0.
If you want to restrict the client to pick the best but not allowing SSL 3.0 anymore have a look at https://stackoverflow.com/a/24237525/3081018 on how to disable SSLv3 by setting the ssl_options.