I want to know whether bot connector service(Microsoft botframework) supports Mutual TLS or not? I want to verify the source of the events coming from bot connector service. I am not able to find any documentation which clearly specifies about mTLS support.
All communications between the bot and the Bot Connector service utilize SSL/TLS for authentication. SSL/TLS connections adhere to the x.509v3 certificate protocol for identifying all HTTPS services (see Authentication with the Bot Connector API).
You can read more about the Azure Bot Service's Data Protection protocol by reading this doc, Encrypt sensitive information in transit.
Additionally, What data is encrypted? can provide additional insight.
Related
Does anyone know if it is possible to have a Websocket Api Gateway support mTLS authentication? According to the documentation it is not supported (https://aws.amazon.com/blogs/compute/evaluating-access-control-methods-to-secure-amazon-api-gateway-apis/). Does anyone know if there is a feature request for this or there is a workaround? We've debated using a lambda authorizer on the $connect route on the websocket API to authenticate client certificates manually, but it seems like an artificial implementation for mTLS since we're performing the client authentication after the TLS handshake. Not sure if this is our best option or if there is something better. Thanks.
I am trying to add an API Gateway to a client-server system, which communicates through WebSockets.
The Server is an audio recognition engine that sits in a remote machine, and clients are connecting to it through WebSockets ('wss://...'), sending audio files and receiving their text translate representation.
My main goal is to add a free open-source API Gateway in the middle in order to authenticate\authorize\rate limit\etc (Tried Kong\Tyk\krakenD, but they are not free).
After searching the web, I focused on Apache APISIX gateway.
As a test, I managed to connect the APISIX to a client-server which communicates by http/https and it worked fine.
Moreover, I managed to connect the client with the server on regular websocket connection (ws://) and the data transactions were successful, but no matter what I do I cant connect to the secured connection. Are there any special configurations I should edit in the dashboard?
I'm wondering if anyone knows from experience if it's possible to use
the secured WebSockets with Apache APISIX and if yes, how exactly it should be done - because the docs are missing any informative info\examples, or if there are better solutions known to my problem.
The only WebSocket reference in APISIX dashboard -
What you should do is create an SSL object (you can find it in the sidebar on the left side). See https://apisix.apache.org/docs/apisix/admin-api/#ssl to learn the APISIX SSL object.
You can see an example at https://apisix.apache.org/docs/apisix/certificate
The SSL object provides the required TLS Certificate and Private Key so that this key pair can be used in a TLS handshake according to the TLS SNI sent from clients. After that, your client established a secured connection with APISIX, and now you can send the WebSocket traffic securely.
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!
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
I wanted to understand the mechanism of message encryption and signing used by NetTcpBinding when 'Windows' credentials are being used with Transport security. What if my AD uses NTLM instead of Kerberos? Will the messages still get signed and encrypted?If so, how?
Thanks in Advance,
Akshat
The short answer is that, yes, with NTLM authentication the messages will still get signed and encrypted if you have set the Transport security ProtectionLevel to EncryptAndSign (the default).
Here's an outline of how it works:
selecting Transport security
configures a
WindowsStreamSecurityBindingElement
in the channel stack. This inserts a
stream upgrade provider (see below)
in the NetTcpBinding, message
exchange between the client and
service happens within the .NET Message
Framing Protocol, which provides both
message framing and a mechanism for
client and service to negotiate
stream upgrades, the principal use of
which is to establish transport
security. If there is a stream
upgrade provider configured in the
channel stack, this will be invoked
during the Preamble stage of the
Framing Protocol when the client
opens the channel.
the upgrade
provider for
WindowsStreamSecurityBindingElement invokes an SSPI handshake between the client and the server using the SPNEGO security package: in the NetTcpBinding this will normally result in Kerberos being selected as the underlying security provider if available, but will choose NTLM if not.
if NTLM is the resulting authentication provider, the SSPI handshake will involve the three-leg NTLM challenge-response exchange of tokens described in the NTLM specification. This protocol includes a mechanism for exchanging keys for message signing and encryption. Once the SSPI handshake has generated an appropriate security context, thereafter all messages exchanged are signed and encrypted in the sending channel stack's stream upgrade provider, and decrypted and verified in the receiving channel stack's stream upgrade provider, in each case by using calls to the NTLM security provider via the abstracted SSPI message support functions.
This is a Microsoft propriety implementation and not properly documented and perhaps on purpose to prevent intruders to take advantage of it.
As far as I know, this usually happens at the TCP level with a special token is generated by the user's credentials and passed along with the request. This is intercepted by windows security channel and authenticated against the AD.
This token is used as a key (or as a basis for generating the key) for encrypting the communication.
I think if you look at the TCP packet, you must be able to see the token - although I have never seen it.
If you are doing this all in code then you can find out the options here (search for 'NetTcpBinding'). Transport security is via Windows builtin TLS.
The diagram here should be helpful for your scenario.