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.
Related
I am currently working on GO app and I wanted to know how can I detect someone using reverse proxy apps such as Charles, Wireshark and Fiddler.
I tried to read about SSL-Pinning but I couldn't find anything useful.
Charles and Fiddler are no reverse proxies but forward proxies. TLS interception in such proxies can be detected based on the certificate returned - it will not be the original server certificate but one created by the server. And certificate validation will fail unless the proxy is specifically trusted by importing the proxies CA certificate. SSL pinning helps too since it expects the server to use a specific certificate or a specific CA - which the SSL intercepting proxy cannot provide.
Wireshark is no kind of proxy but passive packet capturing, i.e. it makes no changes to the traffic. Because it is passive it cannot be detected from inside the client application and SSL pinning would not help either. Wireshark can not decrypt TLS traffic though by its own - it would need to have the connection specific secrets from either inside the client application or inside the server application.
Okhttp how to prevent Fiddler capture https request:
Work with your server’s TLS administrator to adopt certificate pinning. Be careful: certificate pinning done wrong may prevent your app from being able to connect to your server when the server updates its certificates.
If I type out https://http2.golang.org/ the chrome browser will automatically send the HTTP/2 request. How is this done?
Take stackoverflow for example, when the browser sends a request to stackoverflow.com, it has to do the following steps:
DNS lookup. find the ip address of stackoverflow.
TCP/IP handshake
TLS handshake.
HTTP request/response (Application Protocol).
....
TLS handshake
Regarding step3 TLS handshake, there is an nice explanation by #Oleg.
In order to inspect the detail of TCP/IP packet, You may need use some tools to capture packets. e.g. Wireshark.
Client sends ClientHello to server, which carries several things
supported cipher suite. which cipher suites do you like?
supported TLS version.
a random number.
the supported Application Protocols. e.g. HTTP/2, HTTP 1.1/ Spdy/..
...
Server responds SeverHello, which carries
chosen cipher suite.
chosen TLS version.
a random generated number
And, chosen application protocols in TLS application-layer protocol negotiation (ALPN), e.g. HTTP/2
Conclusion
HTTP2 request/response happens in step4. Before that, browser has already know whether sever support HTTP/2 through TLS handshake.
The chrome browser will only send a HTTP/1.1 Request to the website. As the website is HTTP/2 Enabled, it will send a message to the browser that it supports HTTP/2. The server upgrades the communication protocol between it and the server to HTTP/2 if it finds the browser capable of recognizing HTTP/2.
So, it is generally the server which converts a request to the HTTP/2 Connection. The browser just complies with the upgrade policy of the server.
The chrome browser displays that you have a HTTP/2 connection with the server or website, only after the server upgrades the communication protocol.
The string "h2" identifies the protocol where HTTP/2 uses Transport Layer >Security (TLS) [TLS12].
This identifier is used in the TLS application-layer protocol negotiation (ALPN) >extension [TLS-ALPN] field and in any place where HTTP/2 over TLS is identified.
If server support http2.0 browser will find that server is support http2.0 in TLS application-layer protocol negotiation.
refer link!
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 am trying to use Amazon SES on a Amazon EC2 linux server. I tried everything, I am already follow all the tutorials but I cant use the SMTP from my Amazon SES on my application.
the error:
SMTP Error: Could not authenticate.
SMTP Error Message: SMTP -> FROM SERVER:220 email-smtp.amazonaws.com ESMTP SimpleEmailService-222567251
SMTP -> FROM SERVER: 250-email-smtp.amazonaws.com 250-8BITMIME 250-SIZE 10485760 250-STARTTLS 250-AUTH PLAIN LOGIN 250 Ok
SMTP -> ERROR: AUTH not accepted from server: 530 Must issue a STARTTLS command first
SMTP -> FROM SERVER:250 Ok
SMTP Error: Could not authenticate.
Can you use telnet to establish a connection?
This thread has a bunch of suggestions:
https://forums.aws.amazon.com/message.jspa?messageID=301767
From about 2/3 down that thread:
The terminology around SSL and TLS is sometimes used in inconsistent or confusing ways in third-party documentation. I believe the problem you encountered is related to the feature set of those libraries rather than a difference between the way SSL and TLS work. Two different ways of establishing secure connections include STARTTLS and the Handshake Protocol.
STARTTLS provides a way for text protocols (SMTP, IMAP, POP3, etc.) to negotiate a secure connection using TLS/SSL within an existing established plaintext connection.
The Handshake Protocol (aka wrapper mode) supports the establishment of TLS/SSL connections which are secured before the application protocol begins. The Amazon SES SMTP interface currently requires the Handshake Protocol and does not support STARTTLS. We support both SSL 3.0 and TLS 1.0.
The SSL and TLS specifications are a good source of further information about the Handshake Protocol:
•SSL 3.0 specification (RFC 6101)
•TLS 1.0 specification (RFC 2246)
The documentation of Net::SMTP::SSL claims it supports the handshake protocol with SSL, while Net::SMTP::TLS suggests that it supports only STARTTLS not the TLS handshake protocol. I believe the library's lack of support for the handshake protocol explains why it did not work for you.