I am beginner to free switch.I have gone through the configuration file vars.xml in free switch.
In this I have seen the following configurations.
<X-PRE-PROCESS cmd="set" data="internal_auth_calls=true"/>
<X-PRE-PROCESS cmd="set" data="internal_sip_port=5070"/>
<X-PRE-PROCESS cmd="set" data="internal_tls_port=5071"/>
<X-PRE-PROCESS cmd="set" data="internal_ssl_enable=false"/>
<X-PRE-PROCESS cmd="set" data="internal_ssl_dir=$${base_dir}/conf/ssl"/>
In the above I am having the doubt with tls_port.
What is the use of tls_port .I have searched about this in net and I have read that tls protocol is used for secure data transfer in network.
So please explain me about the communication in freeswitch.
Thanks in advance.
Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are two cryptographic protocols which permits to communicate safely and guarantee data integrity over TCP/IP networks, as Internet for example.
TLS e SSL cypher communication end-to-end at transport layer. Other well known protocols as TCP, UDP enable communication at the same layer.
So as TCP uses port 80 by defualt for communication, you must set a port for your TSL protocol in free switch. This is the meaning of tsl_port parameter previously.
Please keep in mind that TLS is disabled by default, set internal_ssl_enable and/or external_ssl_enable to "true" to enable.
if you don't know what TLS is, you just don't need it in freeswitch.
Freeswitch uses TLS to secure the SIP protocol, but SIP will usually work in clear without encryption and often it's also easier to debug SIP with tools such as wireshark without TLS.
Here you can find further information:
http://wiki.freeswitch.org/wiki/Tls#TLS.2C_SSL_and_SRTP_Encryption
In my view it's better if you don't bother with TLS and Secure RTP as long as you are just scratching the surface of FreeSWITCH, there are more interest things to learn first in my view.
Otherwise if you are on a production environment with very strict security requirements you should study not only FreeSWITCH but the relevant RFCs too! ;-)
I have read that Freeswitch has some mailing capability and many mail-server like gmail or yahoo requires the sending client to have TLS connection with them.
Related
Sip (session initiation protocol) does not understand websocket so we need sip proxy which is basically a translator between sip and websocket.
i am following this architecture for sip handshaking with web socket. I have few questions
which sip proxy must be used to make audio and video call. and in the Gateway to SIP module i am using ASTERISK. how asterisk can be used for video call is there any codec available for video call? Please share some useful links.
Your kind answers will be highly appreciated.
Check out http://jssip.net. They provide a javascript API which uses SIP over WebSocket for client-side and they also have a SIP proxy and server (also works with Asterisk,Kamailio). They are the authors of RFC7118 "The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)".
that s only one way to do it. There are many ways.
you have to distinguish between the signaling path and the media path
on the signaling path, you have to choose a signalling protocol and corresponding transport protocol. A browser can use web socket for transport and sip for the protocol as far as signaling is concerned. On the legacy SIP side, you need SID over UDP, there is a need to change the transport of the signaling, not the protocol of the signaling.
On the media path, you have two problems, the encryption and the codec. The encryption is mandatory in webrtc and not in SIP. You need a B2BUA to make the transition between both words.
on the codec side, you either choose an overlapping codec between both words, or you have to transcode. The use of a media server seems mandatory here. If you have multiple parties in a conference, you will need to mix the audio and compose the video to send it to legacy SIP, in which case your media server should be an MCU.
Eventually, you also have a discovery and identity problem. During the original handshake, SIP is expecting a user ID and a domain (which is either a DNS entry or a fixed IP) while webRTC is using ICE. Here again, it is very likely that you need to use a B2BUA to bridge both world.
Asterisk/kamailio/freeswitch are likely to handle most of the above for the simple cases (1 to 1, audio). For anything complicated, you're on your own. You might want to look at respoke.io that was made by digium, the company behind asterisk.
Shall I use WebSocket on non-80 ports? Does it ruin the whole purpose of using existing web/HTTP infrastructures? And I think it no longer fits the name WebSocket on non-80 ports.
If I use WebSocket over other ports, why not just use TCP directly? Or is there any special benefits in the WebSocket protocol itself?
And since current WebSocket handshake is in the form of a HTTP UPGRADE request, does it mean I have to enable HTTP protocol on the port so that WebSocket handshake can be accomplished?
Shall I use WebSocket on non-80 ports? Does it ruin the whole purpose
of using existing web/HTTP infrastructures? And I think it no longer
fits the name WebSocket on non-80 ports.
You can run a webSocket server on any port that your host OS allows and that your client will be allowed to connect to.
However, there are a number of advantages to running it on port 80 (or 443).
Networking infrastructure is generally already deployed and open on port 80 for outbound connections from the places that clients live (like desktop computers, mobile devices, etc...) to the places that servers live (like data centers). So, new holes in the firewall or router configurations, etc... are usually not required in order to deploy a webSocket app on port 80. Configuration changes may be required to run on different ports. For example, many large corporate networks are very picky about what ports outbound connections can be made on and are configured only for certain standard and expected behaviors. Picking a non-standard port for a webSocket connection may not be allowed from some corporate networks. This is the BIG reason to use port 80 (maximum interoperability from private networks that have locked down configurations).
Many webSocket apps running from the browser wish to leverage existing security/login/auth infrastructure already being used on port 80 for the host web page. Using that exact same infrastructure to check authentication of a webSocket connection may be simpler if everything is on the same port.
Some server infrastructures for webSockets (such as socket.io in node.js) use a combined server infrastructure (single process, one listener) to support both HTTP requests and webSockets. This is simpler if both are on the same port.
If I use WebSocket over other ports, why not just use TCP directly? Or
is there any special benefits in the WebSocket protocol itself?
The webSocket protocol was originally defined to work from a browser to a server. There is no generic TCP access from a browser so if you want a persistent socket without custom browser add-ons, then a webSocket is what is offered. As compared to a plain TCP connection, the webSocket protocol offers the ability to leverage HTTP authentication and cookies, a standard way of doing app-level and end-to-end keep-alive ping/pong (TCP offers hop-level keep-alive, but not end-to-end), a built in framing protocol (you'd have to design your own packet formats in TCP) and a lot of libraries that support these higher level features. Basically, webSocket works at a higher level than TCP (using TCP under the covers) and offers more built-in features that most people find useful. For example, if using TCP, one of the first things you have to do is get or design a protocol (a means of expressing your data). This is already built-in with webSocket.
And since current WebSocket handshake is in the form of a HTTP UPGRADE
request, does it mean I have to enable HTTP protocol on the port so
that WebSocket handshake can be accomplished?
You MUST have an HTTP server running on the port that you wish to use webSocket on because all webSocket requests start with an HTTP request. It wouldn't have to be heavily featured HTTP server, but it does have to handle the initial HTTP request.
Yes - Use 443 (ie, the HTTPS port) instead.
There's little reason these days to use port 80 (HTTP) for anything other than a redirection to port 443 (HTTPS), as certification (via services like LetsEncrypt) are easy and free to set up.
The only possible exceptions to this rule are local development, and non-internet facing services.
Should I use a non-standard port?
I suspect this is the intent of your question. To this, I'd argue that doing so adds an unnecessary layer of complication with no obvious benefits. It doesn't add security, and it doesn't make anything easier.
But it does mean that specific firewall exceptions need to be made to host and connect to your websocket server. This means that people accessing your services from a corporate/school/locked down environment are probably not going to be able to use it, unless they can somehow convince management that it is mandatory. I doubt there are many good reasons to exclude your userbase in this way.
But there's nothing stopping you from doing it either...
In my opinion, yes you can. 80 is the default port, but you can change it to any as you like.
I'm working on a study project and need to create a software which should encrypt LAN traffic between computers with Windows. So I need to capture, encrypt and resend all outbound traffic, and capture and decrypt all inbound traffic.
Currently I see two way to do it:
1) IP over UDP. I need encrypt IP packets and send them through UDP link, receive them and decrypt.
2) Encrypt payload of IP packets and decrypt it on another side.
I actually don't know how to do it better and where to start. All suggestions/examples will be helpful.
If you really only need to encrypt the traffic you can simply install a "manually keyed" IPSec SA. See instructions at MSDN
That being said, encryption is the easy part. Authenticating the peers and key agreements is the hard part.
Cryptography is hard to get right, so you definitely want do not want to invent a probably insecure wheel, but opt for a peer-reviewed standard solution, such as the Internet Key Exchange protocol. There is an (unfortunately discontinued) internet draft of a minimal IKE implementation.
Please note that it is perfectly OK to use IKEv2 as the key agreement / authentication protocol for any application - not just for ESP. But if you need to encapsulate ALL IP, Encapsulating Security Payload in tunnel mode is your friend, and the lucky thing here is that ANY OS that is IPv6 compliant MUST implement it, so using ESP is in practice just a matter of installing the key material to your OS kernel's IP stack.
In case you need code samples, I have made a minimal proof-of-concept level implementation of an initiating end of an IKEv2 peer in Python. A Perl implementation doing the same can be found from these IETF proceedings slides
I have a doubt on HTTPS. One of my seniors told me that Https does not actually use SSL/TLS, but only their the encryption algorithms.
He says that the handshaking process with certificates are done in the transport layer, but the security key encryption for actual payload is done in the Application layer.
And he also said that Https can actually be considered as a presentation layer protocol.
Is he correct?
HTTPS is specified in RFC 2818: "HTTP Over TLS".
Although the specification is about TLS (because it's an IETF specification, and IETF only uses "TLS"), it's in fact about SSL or TLS, depending on the version of SSL/TLS used (see difference between SSL and TLS).
So yes, HTTPS does use SSL/TLS. As the RFC says:
Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS
precisely as you would use HTTP over TCP.
Essentially, the encryption keys are negotiated during the SSL/TLS handshake, and the HTTP exchange isn't aware of those keys.
If you're not convinced, look at some browser traffic using Wireshark. All you'll see is some SSL/TLS traffic (the HTTP exchanged being encrypted by it).
If you want to analyse some traffic, you can set up your own server and use its private key to look at the normal HTTP exchange on top of SSL/TLS using Wireshark too, as described in the Wireshark SSL page. (You'll need to disable EDH cipher suites, because they provide perfect forward secrecy, which prevent you from deciphering sniffed traffic even if you have the server private key.)
This page also has some example HTTPS data you can download and look at with Wireshark, without having to install your own server.
From the browser point of view, you can also look at the traffic as reported by the developer tools (Firebug and so on) when using HTTPS, you'll just see plain HTTP traffic, since the SSL/TLS layer is taken care of by the SSL/TLS library underneath.
I wouldn't stress too much about the OSI layers in general. They look good in theoretical networking classes, but are in fact difficult to apply to the TCP/IP stack (see comparison and "layering considered harmful"), especially when you throw SSL/TLS into it, which is precisely designed to be an invisible layer as far as the application layer is concerned (SSL/TLS usually sits on top of TCP, like any other application protocol on top of TCP, but it sits under any application protocol it protects).
Your senior should be your junior. He doesn't know what he is talking about. Avoid him in future. HTTPS is simply HTTP over SSL, with the minor addition of hostname checking to ensure that the hostname in the certificate agrees with the site you connected to.
Specifically:
One of my seniors told me that Https does not actually use SSL/TLS, but only their the encryption algorithms
Wrong.
He says that the handshaking process with certificates are done in the transport layer
Wrong for both SSL and HTTPS. It is done by the application, typically in a library such as OpenSSL or JSSE. The transport layer only does the TCP part, none of the SSL part.
but the security key encryption for actual payload is done in the Application layer.
Wrong again: payload encryption is done in the application layer for both SSL and HTTPS.
And he also said that Https can actually be considered as a presentation layer protocol.
It is an application layer protocol. There are very few examples of presentation layer protocols (XDR and TN3270 comes to mind). This isn't one of them. But I agree with Bruno. The OSI layers are not applicable to TCP/IP, which has its own layer model, and, since the unlamented demise of the OSI protocol effort, they aren't applicable to anything else either.
From Wikipedia:
HTTP operates at the highest layer of the OSI Model, the Application layer; but the security protocol operates at a lower sublayer, encrypting an HTTP message prior to transmission and decrypting a message upon arrival.
https://en.wikipedia.org/wiki/Https#Network_layers
I've been working with zeroMQ a bit and I want to be able to connect securely over the Internet. I'm in ruby and could use SSL and/or some sort of shh connection but cannot find any examples of how to do this.
I found this old stackoverflow link, How does zeromq work together with SSL? saying they were working on some sort of security, but that was a year ago and I can't find any new references.
Even if this isn't built into zeroMQ, I would assume that there would be some way to set this up with OpenSSL or something similar.
Note: zeroMQ website mentions using VPN or something if you want secure transport. I do not want to use VPN. There must be a better way.
Similar to VPN, but much easier to setup:
encrypted tunnel with socat
Let's make each zeromq side connected locally to socat, and two socats connect with each other using encrypted channel.
Some links: [1], [2], [3], [4].
Just wanted to add that since the question was asked, the ZMQ team developed, starting with ZeroMQ v4.0.0, the CurveZMQ protocol, which is an authentication and encryption protocol for ZeroMQ based on CurveCP and NaCl - fast, secure elliptic-curve crypto. This allows encrypted ZMQ message exchange, which would supposedly be secure over the internet.
For more details see Using ZeroMQ Security part 1. Some of the features that were added at the time are:
A new wire protocol, ZMTP 3.0, that adds a security handshake to all
ZeroMQ connections.
A new security protocol, CurveZMQ, that implements "perfect forward security" between two ZeroMQ peers over a TCP connection. I'll
explain CurveZMQ below.
A set of security mechanisms for ZMTP: NULL, PLAIN, and CURVE, each described by their own RFCs. NULL is essentially what we had
before. PLAIN allows simple username and password authentication.
CURVE implements the CurveZMQ protocol.
[...]
For secure messaging over the internet, one would seek to implement, for example, the Ironhouse pattern. See part 2 for a description.
There are certainly Ruby implementations for this protocol, but I did not look for them.
If one is looking for Python implementations, one can look at these resources:
https://github.com/zeromq/pyzmq/tree/master/examples/security
https://developer.ibm.com/tutorials/se-distributed-apps-zeromq-part2/