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
Related
I'm trying to use wireshark to decode, view, and ultimately log my own https traffic--response bodies included. According to the wireshark docs, I need provide the file location of the private RSA key used to decode messages. My question is this:
Where on osx is the private rsa key used in https interactions, is this a single key? Many?
Wireshark docs seem to be telling me to make an RSA key. Given that I'm not experienced enough with this topic, messing with system keys because I read a thing on the internet seems like a pit of despair. What should I do?
What I'm really trying to do is log unencrypted https requests/responses with bodies, while listening to web traffic. If there's a better way I'm all ears.
What I'm really trying to do is log unencrypted https requests/responses with bodies, while listening to web traffic. If there's a better way I'm all ears.
Don't mess around with Wireshark for this. The documentation you're reading is outdated; modern TLS cipher suites do not use pure RSA for key exchange. This configuration was only supported by SSL 2.0, which was superseded by SSL 3.0 in 1996, and is no longer supported by any moern browser. Long story short -- it doesn't actually work in practice.
Instead, use a HTTPS proxy server. Several common tools for this purpose are:
mitmproxy
Charles Proxy (commercial)
fiddler
Many of these tools will also allow you to alter the contents of an HTTPS session, which is certainly not something that Wireshark will do.
Is there any protocol, API or software in existence that can send data/IM/etc directly from one device to another with no server?
Can you not use HTTP GET/POST/DELETE directly between two devices when their device data is known to the user(s)?
I would very much like to know if there is ANY software/protocols that can do this.
thank you!
The internet is build on the Internet Protocol suite. This suite has 5 different layers of protocols: The physical layer, the link layer, the network layer, the transport layer and the application layer. Each depends on the one before.
If you just use the browser, by default HTTP (application layer) is used, which relies on TCP (transport layer), which relies on IP (v4 or v6, network layer), which relies on ethernet (link layer), which finally relies on the actual cable that's plugged into your computer (for WiFi, the first three are the same but the last two differ if I'm not mistaken).
Now to your question: Is there any protocol, API or software in existence that can send data/IM/etc directly from one device to another with no server?
Yes there is. I suggest you start looking at protocols that are in the application layer. To highlight a few standards next to HTTP(S): FTP is for file transfer, IMAP is for emails clients, SMTP is for email servers and SSH is a secure shell which can also be used to tunnel data through.
For your specific case, I think either FTP (FTPS if you want it over SSL), or SSH can be a solution, but it's hard to know for sure without the specifics.
The only thing that these protocols have in common is that one of the two computers will act like server and the other computer as client. This has as downside that port-forwarding might be necessary.
If you've chosen the protocol you'd like to use, then you're up for the next step, selecting a program that can do that for you. For HTTP(S), I'd recommend Apache. If you're using Linux and chose SSH, then you're in luck, there is a build in SSH server in Linux, you can use that. For other protocols, you might just want to search yourself, as I do not have any suggestions.
I hope this answers most of your questions!
Desirius
In browser context, WebRTC is probably what you are looking for: It allows user to user communications.
https://en.wikipedia.org/wiki/WebRTC
https://webrtc.org/
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 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.