i have some questions regarding the SFTP-protocol and the use of HMAC.
In general got the following case:
My client a jsch 0.1.54 lib and talk to an SFTP-server which gives him an algorithm negotiation fail for mac.c2s:
jschProposal="hmac-sha2-256-etm#openssh.com,hmac-sha2-512-etm#openssh.com,hmac-sha1-etm#openssh.com,hmac-sha2-256,hmac-sha2-512"
serverProposal="hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd16"
So for the jsch lib it seems to work if i add all proposal server hmacs "hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd16" but in my understanding it should be enough to support one algorithm or the strongest algorithm of the server.
Could someone explain me how the communication works for that example?
I search a lot but it seems a lot of people add all because it works but not because they know exactly what is to do. Maybe its only for the jsch lib so?
Thanks a lot for your help.
Have a nice day.
Related
I am trying to do an assignment (from another univ's coursepage) which has a line in the starter code (Python with mininet) as
os.system("rmmod tcp_probe; modprobe tcp_probe full=1")
Popen("cat /proc/net/tcpprobe > %s" % (outfile), shell=True)
which gives an error saying that tcp_probe has been disabled.
I found out by googling that tcp_probe has been deprecated in the linux kernel. However it just asks me to 'do the same using ftrace'. I have tried searching online but could not find out how to use ftrace to achieve the same.
Any help is appreciated.
tldr;
Unfortunately, I could not find any way to get TCP tracepoints to work in Mininet, which is what ftrace would uses. The reason for this is that the mininet's /sys/kern/debug directory is empty, i.e., tracing cannot be enabled.
Options:
1. Using mininet-tracing (not recommended)
There probably is a way to get the kernel to include this, or you could use https://github.com/mininet/mininet-tracing which might get you what you need, but I have seen reports that it is slow, and has been updated 9 years ago...
2. Writing a new kernel module (I have tested this and it works)
What I found as a solution instead, was to force printing for the TCP I had in mind and then take a look at the results that way. In order to enable this, you would essentially need to extend some of TCP's behaviour and (quite possibly) reuse the TCP module you have in mind. And create a new kernel module.
Here I have provided an example that you can use. It logs socket information on each ACK. I also included a Makefile and a script to load/unload the kernel module. After you enable the module and let some traffic flow (assuming you are on a debian-based linux) you should be able to find the logs of your TCP in /var/log/kern.log.
Note:
This is a hacky way around the issue, but was good enough for my needs, and hopefully can help someone else too.
My apologies in advance if my question seems a little unprofessional... I am not much of a developer after all.
As part of my university project I need to develop a program that will listen on the network and tell whether the traffic is encrypted or not? What's important is only to know if the traffic coming to a network end is encrypted and it's not really important to know the type and the algorithm of the encryption.
I really have no clue where to begin. I'd appreciate it if anyone could give me some clues on what to look for.
Thanks in advance...
Although the answer of GregS is of course correct, the best way to distinquish encrypted text is to look at the protocol used by the application. For instance, if browsers encrypt anything, it's probably done by using SSL. Remote terminals use SSH.
Although the cipher text is mostly looking as random bytes, you can probably distinquish the encryption protocols. If this is enough depends on your use case. As a first step, many protocols use a specific server port by default; this can be used as a heuristic so you can check the most common protocols for that port first.
We're all familiar with popular protocols like IMAP and POP, used for email messaging.
I have a plan for a new protocol, but I'm not sure to go about implementing it.
Is the protocol a collection of C source code, for example, that accepts and sends data through ports? Or is a protocol just a thorough description of how data should be sent, which clients then implement?
I'm lost where to start here, and I'm not very familiar with how the protocol system works.
Edit:
Also, if I write a protocol and it isn't made official by the standards group, can people/clients still implement it?
The official way is to write an RFC - a Request for Comments. People will respond to that (that's why it's an RFC) and probably try to implement your protocol.
As soon as two independent implementations exist that completely support the protocol, it's a new standard.
Of course, people aren't going to implement a new protocol for someone just for fun. So you should first find a group who is interested in listening to you. Maybe there already is a protocol which does what you want (or can easily be extended).
But you probably don't want to invent a new standard. Standards are a lot of work and - for some - overrated.
So you should describe how it works and create a library that can read and write the protocol, so developers can use it even though it's not an official standard.
As you are interested in the Replace Email section of the Paul Graham article you linked, then IMHO you will need to both develop a protocol definition, and also provide an example implementation. The protocol definition does not need to be published as an internet protocol standard in order to be useful.
You will need an implementation to so that you can test, refine and improve the ideas. It is extremely unlikely the protocol will be right at the first attempt, and you'll need something to support the initial users.
You don't need a protocol definition to implement an improved email, but you will need one if you expect others to work with you and adopt it, though it very much depends on your 'business model'. I strongly recommend you have a protocol definition from the start, even if only to keep yourself sane when you try to produce the second implementation.
I recommend having a look at some examples of sneaky approaches to protocols and implementation. My favourite is described in the Viewpoints Research 2008 Progress report on a super-compact approach to TCP/IP.
They did not follow the traditional approach to developing the implementation of a protocol (the protocol stack). Instead they wrote code which parsed the human-readable TCP/IP protocol specification, and generated the code of a TCP/IP stack from that protocol document. The usual TCP/IP stack is about 40,000 lines of code, or more. Their program, which read the protocol specification, and generated the code for a TCP/IP stack 'automatically' was only 160 lines of code. They use extremly powerful programming tools.
If you had an approach like that, you could keep the protocol implementation synchronised with the specification, and potentially make it straightforward for others to adopt your protocol.
HTH
You are confusing a protocol standard with the implementation.
These 2 are unrelated.
A protocol is described in a high level but has enough information for someone to undestand how it should be implemented.
The idea is that someone reading the document can understand how/what to implement in any language of preference
To give an example: SIP protocol in the RFC describes the various flows and also has the various messages and how they are supposed to b processed i.e. the semantics well defined.
You can implement a SIP UA or Server in C++ or Java. This is irrelevant to the SIP protocol
For this you don't need to provide any source code (you could though if you think it helps clarify some obscurity of the description).
The most important part is that your protocol is actually reviewed by stakeholders i.e. people that expect it to solve their problems.
This part is the most important not only because it could solve problems in your protocol but because they can actually verify that the concept is solid i.e. can be technically implemented
The only case that one could specify something concrete or imply something is if for example the protocol described something demanding some specific constraints e.g. hard-real time constraint which could serve as "hint" on which implementation/languages to avoid
Also, if I write a protocol and it isn't made official by the
standards group, can people/clients still implement it?
Strange question.What do you mean?How will someone know your protocol exists?
If it is official he can get it from the standards group to implement it.
Otherwise it is obvious that you have some sort of "proprietary" protocol (which is not uncommon e.g. a company can have an internal protocol for its own software) and people have to get the spec from you.
Just because of curiosity, I'd like to get to know better, how the Internet works.
I have already read quite some articles in Wikipedia, but these are very theoretical. I know, which protocols are used where, and what they are good for (IP, TCP, HTTP). But I have no idea how these are actually implemented in Linux or any other OS.
So, for me to understand these things better, I'd like to write a simple implementation of the Echo-Protocol in C, preferrably for Linux, and from ground up. My client-application should be able to send a message to a given port on any other computer, and my server-application should be able to receive this message, and send it back to the client.
Where do I start best? What should I read to get more information on these topics? Has anyone of you already done something like this, and if so, what did you learn?
In addition, it would be great if someone could tell me a bout a program that shows me the raw Internet-traffic that runs trough my PC. I think this would also help me understanding things a bit better.
Thanks in advance for your advice.
http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=berkley+socket+tutorial
http://beej.us/guide/bgnet/
http://www.tenouk.com/cnlinuxsockettutorials.html
http://www.paulgriffiths.net/program/c/sockets.php
In addition, it would be great if someone could tell me a bout a program that shows me the raw Internet-traffic that runs trough my PC.
Ethereal is pretty great for this.
There is an interesting problem at hand. I have a role-playing MMOG running through a client application (not a browser) which sends the actions of my player to a server which keeps all the players in sync by sending packets back.
Now, the game uses a top layer protocol over TCP/IP to send the data. However, wireshark does not know what protocol is being used and shows everything beyond the TCP header as a dump.
Further, this dump does not have any plain text strings. Although the game has a chat feature, the chat string being sent is not seen in this dump as plain text anywhere.
My task is to reverse engineer the protocol a little to find some very basic stuff about the data contained in the packets.
Does anybody know why is the chat string not visible as plain text and whether it is likely that a standard top level protocol is being used?
Also, are there any tools which can help to get the data from the dump?
If it's encrypted you do have a chance (in fact, you have a 100% chance if you handle it right): the key must reside somewhere on your computer. Just pop open your favorite debugger, watch for a bit (err, a hundred bytes or so I'd hope) of data to come in from a socket, set a watchpoint on that data, and look at the stack traces of things that access it. If you're really lucky, you might even see it get decrypted in place. If not, you'll probably pick up on the fact that they're using a standard encryption algorithm (they'd be fools not to from a theoretical security standpoint) either by looking at stack traces (if you're lucky) or by using one of the IV / S-box profilers out there (avoid the academic ones, most of them don't work without a lot of trouble). Many encryption algorithms use blocks of "standard data" that can be detected (these are the IVs / S-boxes), these are what you look for in the absence of other information. Whatever you find, google it, and try to override their encryption library to dump the data that's being encrypted/decrypted. From these dumps, it should be relatively easy to see what's going on.
REing an encrypted session can be a lot of fun, but it requires skill with your debugger and lots of reading. It can be frustrating but you won't be sorry if you spend the time to learn how to do it :)
Best guess: encryption, or compression.
Even telnet supports compression over the wire, even though the whole protocol is entirely text based (well, very nearly).
You could try running the data stream through some common compression utilities, but I doubt that'd do much for you, since in all likelihood they don't transmit compression headers, there's simply some predefined values enforced.
If it's infact encryption, then you're pretty much screwed (without much, much more effort that I'm not even going to start to get into).
It's most likely either compressed or encrypted.
If it's encrypted you won't have a chance.
If it's compressed you'll have to somehow figure out which parts of the data are compressed, where the compressed parts start and what the compression algorithm is. If your lucky there will be standard headers that you can identify, although they are probably stripped out to save space.
None of this is simple. Reverse engineering is hard. There aren't any standard tools to help you, you'll just have to investigate and try things until you figure it out. My advice would be to ask the developers for a protocol spec and see if they are willing to help support what you are trying to do.