aeturnus

I was legitimately looking for reviews of this, in hopes of understanding in what capacity it could be more useful than a script, and all I found was this CNet review. To quote, in case it goes down: "DOES NOT WORK" by kdryan2 on July 4, 2009 Pros: No redeeming qualities Cons: Not only did the product not work, it screwed up my settings so I could connect until I manually went in and repaired the damage. Summary: Once again, it does not work -- Just out of curiosity, any ideas what went wrong with that guy's usage? good day.

How about to perform filtering actions on the traffic? Does Kamikaze have something to do something like ettercap's filtering?

This is essentially what I did for my client when this device was requested. I just set up shfs and had tcpdump save the output at a remote location. My client wasn't too concerned with network egress monitoring, and he didn't want everything, just a specific protocol from a single target.

Offensivecomputing.net has a rather large selection of malware.

I apologize if English is not your first language; it's not mine either. But it's very difficult to understand what you're trying to say with improper words being used and terrible grammar. Again though, I think we're on the same page, generally, we just disagree over the terms. Sure. That would be a similar case. It would be easier to do this via HTTPS, but if you're gung-ho for Java* solutions: go for it, it's possible.

Well sure, you can intercept it, that's why no one uses DHE by itself, but follows it up with RSA certificates. I'm not quite sure how a passive attacker could not intercept this sort of traffic, but that's neither here nor there. I'm sure it depends on how you define passive and across what medium the exchange takes place. Nonetheless, if you're interested in this topic, I'd really recommend the books I listed earlier ( Applied Cryptography, Handbook of Applied Cryptography ) as they both cover the topic pretty well ( I have my biases and reservations for both, but either should suffice). Or the O'Reilly book called...something like, "Network Security with OpenSSL", covers the topics rather briefly but has useful code examples if you're wanting to roll your own SSL solution.

I have this odd feeling that you've never read the details of how a DHE exchange works. And Sparda, That's true, you'd have to distribute the certificate to every user that you'd want to use the site. The OP didn't make any mention of how many users he expected. I know that for my work, the "trusted" CA's aren't trusted enough, and we have to use a method of distribution similar to what is described here (although, we don't play around with doing it in Javascript and PHP, we use industry standards for the negotiation of the protocol).

Your post is basically unintelligible. But I can try to surmise what you're trying to say, so please correct me if I'm wrong. Without the client being able to cryptographically validate the server's certificate, the connection can be MITM'd by someone presenting an invalid certificate. Right, that's essentially how that sort of thing works. You can, however, create your own certificates and install it as a trusted root on the client machine through some other secure method. Given the OP's original constraints, this seems reasonable.

I think this somewhat mirrors what someone else said earlier, but really language is irrelevant for the most part. If you're going to write software, the design is much more important, the language comes secondary. So in your case, it really just comes down to what you want to do or what you want to learn. If you want to make easy GUI's and not worry about platform, try Java. If you only want Windows stuff, the .NET languages are great. If you want to be more low-level or work in the kernel, you'll use C and assembly. And whoever suggested MIPS to you probably doesn't know what they're talking about. Your system probably runs x86, unless you're planning on working with embedded devices, then by all means check out MIPS, it's a lot easier to play with. And the byte-code is easier to remember and disassemble in your head. But that's beside the point. Web apps are full of great languages that are all pretty much the same. If you decide on a language you want to try out, tell us-- I'm sure providing tutorials will be easier that way.

No one's arguing against your ability to sniff cleartext, digip. I believe the suggestion was to use Javascript to encrypt the data before sending it to the server. Sparda, The method for the determining if the certificate is valid or not would be the same regardless of whether or not you use the SSL libraries. Your operating system has the trusted CA cache, why can't your home-brew method verify against them? I don't mean to insult anyone's intelligence, but I think the problem is that there's some confusion between implementing a protocol and that protocol "being encryption". SSL is a set of protocols. You can re-implement those protocols in another language without using pre-made libraries and they will act just the same. You don't suddenly lose the ability to verify RSA certificates by using your systems trusted roots just because you choose to not use mod_ssl.

The attack you're talking about was one way, and it relied on a lot of tech. I'm suggesting that there are possible other ways to fake a trusted CA, maybe not involving lots of tech. Perhaps breaking into the building where the information is stored. Or perhaps there's a publicly unknown break in SHA-1 that people are currently using to keep themselves afloat in a struggling economy. Although unlikely, those avenues are still possible methods of pursuit-- and before the MD5 break a few years ago, I'd probably say they were all equally likely. So you're saying there's no possible way to MITM an SSL stream? Yeah, that sounds reasonable, sure. [/sarcasm] Sure, I'm saying the OP could do the math himself. After all, we're all big boys and girls here and we can all read Applied Cryptography, the Handbook of Applied Cryptography, or hey, maybe even the OpenSSL source code.

Well, you're assuming that the only way to create a rogue CA is to use a bunch of PS3's playing with MD5 and hoping you get the right information from the CA. And that's simply not the case. That is sort of off-topic, though. If the OP really wants to do this all in PHP and Javascript, I don't think we should tell him it's not possible. He could perform a DHE exchange that way and incorporate RSA certs, effectively doing the SSL without using the SSL libraries. Or use a salted PSK, or many other ways. I think we've all clearly suggested that using SSL is the superior plan of attack, but if he really doesn't want to do it, shouldn't we be suggesting options that fit his requirements?

That's of course assuming that the attacker didn't create a rogue CA, or recover the private key of a trusted CA. I agree with you and stringwray that a Javascript solution does not provide the same level of security as a full, properly configured, SSL session. But, at the same time, the OP doesn't seem to be too concerned with security and it would fit his requirements. It doesn't fail, it just becomes more difficult since the admin has to do more than just set a domain policy and wait for angry users to call. But of course, you could implement the policy features yourself, server-side, that checks for the requirements you're looking for.

Well, the OP could create a shared-secret using a PSK and Javascript to create the level of security I think he's looking for.

Well, it's possibly a failed attack, especially since the OP said that each packet is a few seconds apart. Are you getting more than the SYN? It's likely something more than someone playing with spoofing his IP if you're getting more than the SYN. If it's bothering you, you could always report it to the ISP.