I have learned a little about https, but was not clear why it is needed.
What if I encrypt the data using the most powerful algorithms like RSA instead of sending through a HTTPS zone? Can someone explain with a few reasons why we need https?
On the Wikipedia article it says
Technically, it is not a protocol in itself; rather, it is the result
of simply layering the Hypertext Transfer Protocol (HTTP) on top of
the SSL/TLS protocol
On the SSL/TLS article on Wikipeida,
TLS and SSL encrypt the segments of network connections at the
Application Layer for the Transport Layer, using asymmetric
cryptography for key exchange, symmetric encryption for
confidentiality, and message authentication codes for message
integrity.
So the key exchange does use asymmetric cryptography and RSA is an asymmetric cryptography algorithm.
After key exchange has been performed in a secure manner further communication can be done through symmetric cryptographic algorithms. The reasoning behind using both symmetric and asymmetric algorithms can be found here.
What if I encrypt the data using the most powerful algorithms like RSA
instead of sending through a HTTPS zone?
You will have to implement all by yourself, i.e. reinvent the wheel. HTTPS is by default supported in every browser.
Can someone explain with a few reasons why we need https?
Secure communication that is widely supported. If you have in the middle of communication someone with sniffer tool like Wireshark, he/she will be able to see all packets that you and your peer exchange. Try to catch the HTTPS communication, you won't be able to see anything meaningful in the body of the request.
You could indeed encrypt the data by yourself, but you will face a big problem: The encrypting code must be available on the server as well as on the client (normally the browser).
Implementing the encryption on the server can be done securely. On the client side you can either install a software (plugin), or you can send JavaScript to the client. The problem is: how do you get the encrypting code to the client? Everybody evesdropping, will get the javascript code as well, so he can do the same things as the client will be able to do.
Instead of forcing the user to install a plugin, you can use the built-in support for SSL, every browser understands this protocol already. You could think of it, as an already installed plugin for encryption.
Related
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/
I'm trying to develop a XMPP "Proxy" which will be in the middle of a standard Jabber communication.
The schema will be something like this:
Pidgin ---> Proxy <--- eJabberD
|
v
Console
The purpose of this proxy is to log all the stanzas which go over the wire. IMHO, this is very convenient when you're developing XMPP based solutions.
I'm doing this with EventMachine and Ruby, and the main problem is to know how to decypher the traffic after the TLS/SASL handshake.
Before the starttls, all works perfectly, the server and client can talk between them, but when the tls handshake begins, although it works, it is impossible to dump the clear content as all of the traffic is encrypted.
I'm not an expert in TLS/SASL thing, so I don't know which is the best approach to do this. I think one way to achieve this, should be to grab the certificate in the handshake and use it to decypher the content as it goes throught the proxy.
Thanks!
If you could do what you say (grab the certificate on the wire and use it to decrypt), then TLS would be pretty worthless. This is one of the primary attacks TLS exists to prevent.
If the server will allow it, just don't send starttls. This is not required by spec. If starttls is required by your server, then you can configure it to use a null cipher, which will leave the traffic unencrypted. Not all servers will support that of course.
You can man-in-the-middle the starttls. Respond with your own tunnel to the client, and send a separate starttls negotiation to the server. This should generate certificate warnings on the client, but since you control the client you can tell it to accept the certificate anyway.
If you control the server, you can use the private key from it to decrypt the traffic. I'm not aware with any off-the-shelf code to do that easily, but it's writable.
I want to know how HTTPS is implemented. Whether the data is encrypted or path is encrypted (through which data is passed). I will be thankful if someone provides me implementation details.
Very simply, HTTPS uses Secure Socket Layer to encrypt data that is transferred between client and server. SSL uses the RSA algorithm https://en.wikipedia.org/wiki/RSA_(cryptosystem), an asymmetric encryption technology. The precise details of how the algorithm works is complex, but basically it leverages the fact that whilst multiplying two large prime numbers together is easy, factoring the result back into the constituent primes is very, very hard. How all SSL/RSA encryption works is:
The server generates two large prime numbers, and multiplies them together. This is called the "public key". This key is made available to any client which wishes to transmit data securely to the server. The client uses this "public key" to encrypt data it wishes to send. Now because this is an asymmetric algorithm, the public key cannot be used to decrypt the transmitted data, only encrypt it. In order to decrypt, you need the original prime numbers, and only the server has these (the "private key"). On receiving the encrypted data, the server uses its private key to decrypt the transmission.
In the case of you browsing the web, your browser gives the server its public key. The server uses this key to encrypt data to be sent to your browser, which then uses its private key to decrypt.
So yes all data transmitted to/from server over HTTPs is encrypted - and encrypted well. Typical SSL implementations use 128 or 256 digits for their keys. To break this you need a truly vast amount of computing resources.
As far as I am aware the request for a server asset is not encrypted - use httpfox https://addons.mozilla.org/en-US/firefox/addon/6647/ or Wireshark http://www.wireshark.org/ or something to confirm.
In two ways.
By ensuring that all information transmitted between you and the website is encrypted. It does this via a key-exchange process using RSA (which exchanges a 'session key', which is used for the actual encryption).
By (trying to) demonstrate trust in the website you visit. Certificates are provided to domains, and the idea is that on your machine you trust only certificates from various reputable sources. Then, you can (in theory) be assured that when a certificate pops up for "Your Bank", it is really "Your Bank" website, and not some other website. In practice, very few people care/notice this aspect of SSL.
It's transport layer security. It is not application level. You still need to follow secure coding practices and various other techniques to ensure that your site is secure.
I thought this was a really concise human readable explanation:
http://robertheaton.com/2014/03/27/how-does-https-actually-work/
Here is my summarised version:
Concepts:
Asymmetric cryptography algorithm – Public key encryption, private
key decryption.
Symmetric cryptography algorithm – Public key
encryption and decryption.
Handshake:
Hello – Client send cryptography algorithm and the SSL version it supports.
Certificate Exchange – Server sends certificate to identify itself, and certificate public key.
Key Exchange – The client uses Certificate public key to encrypt a new client regenerated public key (using the agreed asymmetric cryptography algorithm from step 1) and sends it to the server. The server decrypts it using its private key (using asymmetric cryptography algorithm).
Data Exchange - This public key is now know by both client and server. It is used for subsequent requests/responses for both encryption and decryption on both client and server (symmetric cryptography algorithm)
You can read all the details in the TLSv1 RFC-2246.
For security analysis, specifically the following section:
F. Security analysis
The TLS protocol is designed to establish a secure connection between
a client and a server communicating over an insecure channel. This
document makes several traditional assumptions, including that
attackers have substantial computational resources and cannot obtain
secret information from sources outside the protocol. Attackers are
assumed to have the ability to capture, modify, delete, replay, and
otherwise tamper with messages sent over the communication channel.
This appendix outlines how TLS has been designed to resist a variety
of attacks.
further content snipped
Server and client do not have control over the path that is used to transmit the data. The path used is a matter for the network layer (Internet Protocol - IP), not for the Transport Layer Security (TLS)
The data itself is encrypted, and there are also means for checking server autenticity, as mentioned by Noon Silk.
http://en.wikipedia.org/wiki/Transport_Layer_Security