I'm working on adding SSL support into our existing application and have started to think about backwards compatibility.
The one special case that makes this different than other posts I've read is the server may not necessarily be updated with SSL code. So I'll have an SSL client connecting to a server that knows nothing about SSL.
For the sake of this discussion, the application sends keystrokes one at a time to the server, and for each keystroke a new socket is created. So I need to figure out a way to make this work on the existing port number and not use timeouts to determine if the server supports SSL or not.
Any suggestions on a graceful way to handle this?
(I'm using Winsock and OpenSSL)
Usually applications accept plain connections and direct SSL connections on different ports, e.g. smtp port 25 and smtps port 465, http port 80 and https port 443 etc. Other ways are to use the same port and then have a specific command from the client to upgrade to SSL, e.g. like STARTTLS with smtp or AUTH TLS with ftp.
If these common ways are not an option for you and the client sends the first packet in your protocol anyway (like with http, but not with smtp or ftp) you might do an recv(..MSG_PEEK) after the initial accept to see, what kind of data the client sends without removing the data from the socket buffer yet. If the peeked data look like your plain application protocol you continue there, if they look like a client hello from SSL (see https://security.stackexchange.com/questions/34780/checking-client-hello-for-https-classification) you do an SSL upgrade.
Related
I'm working on an academic project about TLS handshakes and i have captured some TLS traffic generated by multiple clients (google chrome, firefox...) and I want to see if for a given browser the client hello message will always be the same or no (I have removed the GREASE extensions because they are added in a random way to the client hello message and I omitted the SNI). I found that the same browser generate multiple client hello messages.
Is it normal to see such behavior or I'm doing something wrong?
A TLS handshake is done for each TCP connection involved in HTTPS and it is common that the browser uses multiple TCP connections in parallel. This is probably what you see. Multiple TLS handshakes within the same TCP connection are uncommon but might happen if a server requires a client certificate only for a specific path and thus triggers a renegotiation.
I installed Wowza and is Streaming by this links:
HTTP:
http ://[my-ip]:1935/myapp/definst/mp4:00.Intro.mp4/manifest.mpd
and also on
http ://[my-subdomain]:1935/myapp/definst/mp4:00.Intro.mp4/manifest.mpd
When is config Wowza to be able to stream on port 80, it works again on these links:
http ://[my-ip]/myapp/definst/mp4:00.Intro.mp4/manifest.mpd
http ://[my-subdomain]/myapp/definst/mp4:00.Intro.mp4/manifest.mpd
but we must stream over SSL protocol.
means: HTTPS:
https ://[my-subdomain]/myapp/definst/mp4:00.Intro.mp4/manifest.mpd
We installed a wildcard SSL on our server and everything is working great. In general, port 1935 does not work over HTTPS! even when we add port 80 to Wowza, HTTPS connection is refused and we can't have streaming over https.
How can we stream over SSL on wowza? even with or without port 1935
Thanks
Yes, Wowza server supports streaming with SSL using StreamLock or your own SSL certificate.
You will need to set up a different port number for HTTPS. It could be that another process is using port 80. Port 443 is typically used.
From the Server tab, click Edit.
Click Add Host Port and fill in fields.
Check Enable SSL/StreamLock.
Save and re-start Wowza server.
Look in [install-dir]/logs/wowzastreamingengine_access.log for errors. It will give a clue as to whether there is a problem with the certificate, password or other.
I was recommend place a LB infront of my Wowza for SSL offloading so you can load the m3u8 over SSL. I was also told you can do that quite easily using HA Proxy for example. It is explained how to accomplish this here for RTMP but the same can obviously done with HTTP:
https://github.com/arut/nginx-rtmp-module/issues/457#issuecomment-250783255
Note, I have not tried this yet and I am unclear on exactly the proper use scenario. Nor, have I successfully enable StreamLock with my own cert nor the cert provided through Wowza. If I manage to do so I will update this thread. Hope this is helpful.
I'm adding TLS/SSL option to my email client using openssl. 3 options can be selected: AUTO, TLS, SSL (like Outlook Express's "encrypted connection option").
I'm curious that when 'AUTO' option selected, how it should work?
How can I select the best option for a specific mail server?
If I have to try the options one by one by priority (maybe TLS -> SSL -> none), how can I check the attempt fails?
Any advice will be welcomed.
First, make the determination based on the port number. The secure e-mail ports are 993 for IMAP and 995 for POP3. So if you're connecting to either of these ports, use TLS or SSL to connect.
If the port number is standard IMAP 143 or POP3 110, then you need to do an unsecure connection and query the capabilities of the mail server. You initiate a secure connection with the STARTTLS command.
During TLS negotiation, you tell the server what you're capable of (TLSv1 and SSLv3 for example) and the server picks which one to use.
If you have an AUTO option, you should show a "lock" icon or some other indicator in the user interface so that the user knows whether or not the connection is encrypted. Otherwise they'd have no idea which connection method you used.
You may want to look at this article on how Thunderbird does it.
Le'ts say you open a tcp socket on port 80 to handle http request, and a ssl socket on port 443 to deal with https...how can some proxy provide access to both of them on the same port??
I found only this link but it wasn't very useful. Can you provide me an erlang example or suggest me some resources from which i can learn more on the topic?
Thanks in advance
how can some proxy provide access to both of them on the same port??
By implementing the HTTP CONNECT method, the (non-transparent) proxy may switch to providing a TCP tunnel over which a browser may, for example, access an HTTPS resource.
A rather sparse specification:
https://www.rfc-editor.org/rfc/rfc2616#section-9.9
As outlined in the link you provide, you will need to write your own custom server that sniffs the request and then redirects to the correct protocol accordingly.
As http://www.faqs.org/rfcs/rfc2818.html indicates, an HTTP session will start with an Initial Request Line (e.g. GET /), whereas a TLS session will start with a ClientHello (more on the TLS session on wikipedia)
There are lots of resources online about writing servers in Erlang, e.g. How to write a simple webserver in Erlang?
Incidentally your terminology is incorrect: http, https SSL and TLS are protocols, and all operate (over the web) using TCP sockets.
Most mail clients that support SSL/TLS only require the user to say whether or not SSL should be enabled. The user doesn't have to know anything about Explicit & Implicit SSL and the differences between them.
So, how does the mail client determine which type of SSL to use? Is it based on default port numbers? Does it just try one and then the other?
A mail client must know if implicit SSL is in use when it connects, as it is responsible for initiating the SSL handshake with a ClientHello message. How it determines this is up to the client. Port numbers are a great hint, but there could also be a check box in some UI that forces it even when the standard (unprotected) port number is used.
There are IANA registered port numbers for secure mail, but some ISPs may use other ports.
IMAP/SSL: 993
POP3/SSL: 995
SMTP/SSL is often offered on port 465, but this is not registered, and is less common since support for explicit SSL is widely supported by SMTP agents.
Support for explicit SSL can be advertised by a server using a protocol-specific negotiation. For example, when a client connects to an SMTP server, and issues the EHLO command, the server will list its capabilities, which might include support for the STARTTLS command.
Port 465 is very common among commercial mail servers and is used very often. Most often it used for implicit SSL. When you telnet to this port you will get a timeout since you must set up the SSL connection first before communications with the mail server. Thus a timeout may be the first clue you have an implicit SSL connection. You cannot use EHLO to return results because no connection other than an SSL connection is allowed. AND NO you do not simply connect to an SMTP server running implicit SSL it will not respond and will just drop the connection. That is what it is supposed to do. Explicit SSL will allow connection first and then set up SSL. AND yes implicit SSL is used often. The drawback is that the RFC standards are not specific as to how it is implemented so different developers set it up in varying ways, even though implicit SSL is considered by some as depreciated.
I believe most clients that support SMTP over SSL start out with an unencrypted connection and issue an EHLO rather than HELO. The former has extra flag responses, one of which indicates whether the server supports the STARTTLS command or not. If they do, then the client can use STARTTLS, and then use SSL from that point on.
Example:
% telnet quack.kfu.com 25
220 quack.kfu.com ESMTP ready NO UCE
EHLO client
250-quack.kfu.com Hello client [xx.xx.xx.xx] (may be forged), pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE 25000000
250-ETRN
250-AUTH PLAIN LOGIN
250-STARTTLS
250-DELIVERBY
250 HELP
starttls
220 2.0.0 Ready to start TLS