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
Related
Blazor Server development is great! One of my concerns is with the security of data being sent through SignalR/WebSockets.
From my understanding the communication between client and server is:
Action is taken by user e.g. clicks button
Javascript innovates the WebSocket communication with my server
Server responds with data that I've returned
Javascript changes the page (DOM)
From Chrome developer tools I can see this happening on the websocket i.e. wss://localhost/_blazor?id=XXXXXXXXXXXXXX. As the websocket is wss:// I thought communication was secure and ensured integrity and confidentiality e.g. man-in-the-middle attacks etc
So why has Microsoft advised to "Always user HTTPS" in their Blazor Server Threat Migration documentation?
Protect information in transit with HTTPS
Blazor Server uses SignalR for communication between the client and
the server. Blazor Server normally uses the transport that SignalR
negotiates, which is typically WebSockets.
Blazor Server doesn't ensure the integrity and confidentiality of the
data sent between the server and the client. Always use HTTPS.
https://learn.microsoft.com/en-us/aspnet/core/blazor/security/server/threat-mitigation?view=aspnetcore-6.0#protect-information-in-transit-with-https
Thank you to Brennan for answering my question in the comments.
So why has Microsoft advised to "Always user HTTPS" in their Blazor Server Threat Migration documentation?
The warning is just general text. The two statements on the documentation are independent of each other.
The below explains the mechanism Blazor Server typically uses for communication between client and server i.e. WebSockets
Protect information in transit with HTTPS
Blazor Server uses SignalR for communication between the client and the server. Blazor Server normally uses the transport that SignalR negotiates, which is typically WebSockets.
The below states you should always use a secure protocol when communicating between client and server i.e. HTTPS
Blazor Server doesn't ensure the integrity and confidentiality of the data sent between the server and the client. Always use HTTPS.
I assumed Microsoft was referring to using standard API (HTTP/2) endpoints to ensure integrity and confidentiality. As Brennan pointed out - WebSockets is an extension of HTTP/1.1, and thus can use HTTPS.
Hopefully, this helps people in the future.
I am setting up hubot with a slack adapter for an enterprise and would like to know if the socket connection between Hubot and Slack is secure.
If not, how can it be secured?
Its hard to say in general whether a product would be regards as "secure" for your enterprise. It all depends on the security requirements specific to your business. e.g. a defense contractor might have much higher security requirements than a retailer.
To answer your question I would therefore suggest to research the security specifics of this product and then compare them with the security requirements of your enterprise.
Here is an overview about the security architecture to get you started:
Hubot uses Slack's RTM API which uses WebSockets as main
communication protocol
To start a connection you need to call either the rtm.start or
rtm.connect endpoint, which is secured by HTTPS. Both endpoints require you to
provide authentication via a Oauth 2.0 token.
Those endpoint return a custom URL for your WebSocket session
All WebSocket communication uses the secure WSS protocol, which applies TLS to secure the connection
I have raised a ticket with Slack support team and they confirmed that connection is WSS and uses TLS 1.2 which makes it secure for enterprise. Thanks!
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!!!
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
I need to connect to Exchange Server in Mule but Mule provided OOB IMAP and POP3 are not enabled on our exchange server hence we cannot use them.
Can anyone shed some light here on other alternative ways to connect to exchange server and read the emails.
Mule mail transport implements standard transports, these being IMAP, POP3 and SMTP.
If you need anything beside these to access your mail server you should consider writing a custom connector using devkit.
An example of such an approach is the gmail connector that leverages google API to retrieve emails rather than the standard mail transport.
Most of the connections from the Internet are handled by IIS on the Exchange Server. The options can be:
RPC Over Https. Well known as “Outlook Anywhere”.
EWS. Mostly used by MAC Outlook.
Activesync – Mobility
ECP – management console, configuration via OWA
Thanks,
hope answer the question