java

JNetBridge: Java Library to Send/Receive Network Packets

abb — Sat, 05 Feb 2011 20:42:27 +0000

JNetBridge: Java Library to Send/Receive Network Packets

I am releasing jnetbridge, which will be responsible for receiving and sending network packets in Marvin 0.92 (the current version, 0.91, still uses jpcap). It is based on JNetPcap (JNI adapter to libpcap/winpcap + protocol analyzer in Java). JNetBridge is a small piece of code on top of the massive JNetPcap library.

To cut the long story short, below is a bunch of files you may want to have a look at, if you are Java developer trying to implement some sort of a network bridge or a router.

README.TXT
TransparentBridge.java - a simple example
jnetbridge-javadoc-0.2
jnetbridge-src-0.2
jnetbridge-bin-0.2

The code is released under LGPL, like JNetPcap itself.

abb Sat, 02/05/2011 - 21:42

Enabling SSL/TLS Renegotiation in Java

alla — Tue, 08 Jun 2010 12:40:29 +0000

Enabling SSL/TLS Renegotiation in Java

All the crazy SSL servers seem to come my way - ones that only support weird combinations of protocols and ciphers, ones that require client certificates stored on PKCS#11 hardware, and ones that require SSL renegotiation.

Turns out that Sun has recently disabled SSL/TLS renegotiation in Java by default as a workaround for SSL/TLS renegotiation vulnerability. This becomes a problem when trying to test an HTTPS server that actually requires renegotiation. Burp suite reacts to it with an error message saying "javax.net.ssl.SSLException: HelloRequest followed by an unexpected handshake message" or, if I enable only TLSv1, with a message saying "javax.net.ssl.SSLHandshakeException: renegotiation is not allowed". I expect that other Java-based proxies, such as WebScarab behave in a similar way.

Fortunately, renegotiation can be explicitly enabled by setting the Java system property system property sun.security.ssl.allowUnsafeRenegotiation to true. For example, to run Burp suite we can do :

java -Dsun.security.ssl.allowUnsafeRenegotiation=true -jar burpsuite_pro_v1.3.04.jar

alla Tue, 06/08/2010 - 14:40

Autocomplete and Input History for MagicTree

alla — Thu, 11 Feb 2010 17:54:40 +0000

Autocomplete and Input History for MagicTree

Components for Java Swing

Most modern user interfaces remember user input and provide autocomplete function. When you start typing a URL in a browser location bar, you get a list of URLs matching the pattern you have typed.

We wanted similar functionality for MagicTree. Whenever user has to type something, whether it is a command line, an XPath expression or a search term, we wanted the application to remember the previous input and provide autocompletion. Now we have that:

This functionality seems to be generally useful, so I decided to publish the components I have developed.

The main building block of the History package is the History class. It is not a GUI component, but rather a store for user input history. It is backed by Java preferences, so input history is stored between application invocations. This class also keeps statistics about the usage of each history item, so the user is presented with suggestions with most often used strings coming first. This class also allows to have multiple separate input histories in the application. For example, you may want to have a separate history for street name field and for city name field.

The package provides three GUI components: HistoryTextField inherited from JTextField, HistoryComboBox inherited from JComboBox and HistoryCellEditor implementing TableCellEditor interface. You can also use HistoryDocument inherited from PlainDocument to provide autocompletion for any other GUI component inherited from JTextComponent.

Download [attachment:gremwell-history.jar=binary jar], [attachment:gremwell-history-src.zip=source code], and [attachment:gremwell-history-javadoc.zip=javadoc] for gremwell-history package.

Update: I have uploaded a new version. It fixes a problem preventing long history entries (Java preferences only allows keys up to 80 characters long) and a bug in HistoryComboBox which caused autocomplete when the component lost focus.

alla Thu, 02/11/2010 - 18:54