Merge pull request #1 from fcorneli/master

getting started again...
pom.xml: use newer JBoss repository, the old one got closed
Specify weaker ciphers because of Java 7 regression

Firefox 20 works fine, but subversion 1.7.8 fails with the below stacktrace:

javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: java.security.ProviderException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DOMAIN_PARAMS_INVALID
javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: java.security.ProviderException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DOMAIN_PARAMS_INVALID
        at sun.security.ssl.SSLSocketImpl.checkEOF(SSLSocketImpl.java:1492)
        at sun.security.ssl.AppInputStream.read(AppInputStream.java:92)
        at sun.security.ssl.AppInputStream.read(AppInputStream.java:69)
        at org.owasp.webscarab.model.Message.readLine(Message.java:440)
        at org.owasp.webscarab.model.Request.read(Request.java:98)
        at org.owasp.webscarab.plugin.proxy.ConnectionHandler.run(ConnectionHandler.java:186)
        at java.lang.Thread.run(Thread.java:722)
Caused by: javax.net.ssl.SSLException: java.security.ProviderException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DOMAIN_PARAMS_INVALID
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
        at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1902)
        at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1860)
        at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1843)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1362)
        at sun.security.ssl.SSLSocketImpl.getSession(SSLSocketImpl.java:2189)
        at org.owasp.webscarab.plugin.proxy.ConnectionHandler.negotiateSSL(ConnectionHandler.java:323)
        at org.owasp.webscarab.plugin.proxy.ConnectionHandler.run(ConnectionHandler.java:144)
        ... 1 more
Caused by: java.security.ProviderException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DOMAIN_PARAMS_INVALID
        at sun.security.pkcs11.P11KeyPairGenerator.generateKeyPair(P11KeyPairGenerator.java:323)
        at java.security.KeyPairGenerator$Delegate.generateKeyPair(KeyPairGenerator.java:687)
        at sun.security.ssl.ECDHCrypt.<init>(ECDHCrypt.java:63)
        at sun.security.ssl.ServerHandshaker.setupEphemeralECDHKeys(ServerHandshaker.java:1206)
        at sun.security.ssl.ServerHandshaker.trySetCipherSuite(ServerHandshaker.java:1060)
        at sun.security.ssl.ServerHandshaker.chooseCipherSuite(ServerHandshaker.java:887)
        at sun.security.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:620)
        at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:167)
        at sun.security.ssl.Handshaker.processLoop(Handshaker.java:868)
        at sun.security.ssl.Handshaker.process_record(Handshaker.java:804)
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1032)
        at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1328)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1355)
        ... 4 more
Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DOMAIN_PARAMS_INVALID
        at sun.security.pkcs11.wrapper.PKCS11.C_GenerateKeyPair(Native Method)
        at sun.security.pkcs11.P11KeyPairGenerator.generateKeyPair(P11KeyPairGenerator.java:314)
        ... 16 more
.gitignore: Ignore build and dist directories
Merge pull request #3 from Lekensteyn/fixes

Build fixes
Merge pull request #4 from Lekensteyn/java7-workaround

Specify weaker ciphers because of Java 7 regression
Set SSL issue date to one month ago

This fixes an issue where the client trusts the CA, but where the clocks are not
synchronized.
Do not drop unrecognized Authorization headers

The Authorization may contain schemes other than Basic. Before this patch,
"Authorization: GoogleLogin ..." was silently dropped which broke an
application.

After this patch, constructAuthenticationHeader still return null when
challenges are given but negotiation fail (when headers WWW-Authenticate
or Proxy-Authenticate are given). But instead of returning null when
the authorization scheme is unrecognized, return the credentials string (the
string that is given to Proxy-Authorization or Authorization).
Merge pull request #5 from Lekensteyn/fixes

Fixes: SSL issue date and avoid dropping unrecognized Authentication header
Support TLSv1-only servers
Perform TLS handshake during connection setup

This catches fatal TLS handshake errors earlier which makes the stack traces
more logical. Without this, the handshake would be performed when the output
stream is written.
Workaround for Java bailing out on TLS warning due to SNI

Java 7 supports the SNI extension and sends the host name in the `server_name`
extension. Some misconfigured servers (Apache only?) that support SNI send an
"Unrecognized Name" warning that kills Java 7. Oracle engineers refuse[1] to
fix this error that is not as rare as it sounds[2].

According to RFC 3546 (TLS Extensions) [3], servers *should* send the
unrecognized_name alert which *may* be fatal. In practise, clients just ignore
this (tested with wget, curl, Firefox, Chromium).

This patch makes Webscarab perform a second connection attempt without a Host
header (effectively disabling SNI), when the exception message indicates that
the "unrecognized_name" alert was received.

Tested with https://redhat.com/ and https://webmail.arago.utwente.nl/.

 [1]: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127374
 [2]: http://stackoverflow.com/q/7615645/427545
 [3]: http://www.ietf.org/rfc/rfc3546.txt
Merge pull request #7 from Lekensteyn/fixes

TLS (1.0) support and workaround for SNI breakage in Java 7
Really accept all certificates in Java 7

In Java 7, a new X509ExtendedTrustManager class is introduced and the old
X509TrustManager implementations are wrapped in
`src/share/classes/sun/security/ssl/SSLContextImpl.java` using
`AbstractTrustManagerWrapper`. This class always checks the algorithm
constraints which may therefore reject some certificates that are signed with
an insecure algorithm (for example, MD2withRSA). By providing a full
X509ExtendedTrustManager implementation, this wrapper is not used and all
certificates get accepted.

Note: Java 6 does not have a X509ExtendedTrustManager class.
Provide a dummy X509ExtendedTrustManager

Java 6 does not have the X509ExtendedTrustManager class, but since
ClientTrustedManager needs to be extended from it in Java 7 a compatibility
class needs to be shipped with Java 6.
Show finest messages too, allow custom console LogLevel
logger: Use different method to enforce auto-scroll

Prevent WebScarab from crashing after logging binary data:

java.util.logging.ErrorManager: 1
java.lang.IllegalArgumentException: TextHitInfo is out of range
        at java.awt.font.TextLayout.checkTextHit(TextLayout.java:771)
        at java.awt.font.TextLayout.getCaretInfo(TextLayout.java:1211)
        at java.awt.font.TextLayout.getCaretInfo(TextLayout.java:1313)
        at javax.swing.text.GlyphPainter2.getSpan(GlyphPainter2.java:82)
        at javax.swing.text.GlyphView.getPartialSpan(GlyphView.java:330)
        at javax.swing.text.GlyphView.getMinimumSpan(GlyphView.java:556)
        at javax.swing.text.ParagraphView.calculateMinorAxisRequirements(ParagraphView.java:731)
        at javax.swing.plaf.basic.BasicTextAreaUI$PlainParagraph.calculateMinorAxisRequirements(BasicTextAreaUI.java:272)
        at javax.swing.text.BoxView.checkRequests(BoxView.java:935)
        at javax.swing.text.BoxView.getMinimumSpan(BoxView.java:568)
        at javax.swing.text.BoxView.calculateMinorAxisRequirements(BoxView.java:903)
        at javax.swing.text.BoxView.checkRequests(BoxView.java:935)
        at javax.swing.text.BoxView.setSpanOnAxis(BoxView.java:343)
        at javax.swing.text.BoxView.layout(BoxView.java:708)
        at javax.swing.text.BoxView.setSize(BoxView.java:397)
        at javax.swing.plaf.basic.BasicTextUI$RootView.setSize(BasicTextUI.java:1714)
        at javax.swing.plaf.basic.BasicTextUI.modelToView(BasicTextUI.java:1046)
        at org.owasp.webscarab.ui.swing.UIFramework$TextScroller.insertUpdate(UIFramework.java:919)
        at javax.swing.text.AbstractDocument.fireInsertUpdate(AbstractDocument.java:202)
        at javax.swing.text.AbstractDocument.handleInsertString(AbstractDocument.java:749)
        at javax.swing.text.AbstractDocument.insertString(AbstractDocument.java:708)
        at javax.swing.text.PlainDocument.insertString(PlainDocument.java:130)
        at org.owasp.webscarab.util.swing.DocumentHandler$1.run(DocumentHandler.java:97)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
        at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:727)
        at java.awt.EventQueue.access$200(EventQueue.java:103)
        at java.awt.EventQueue$3.run(EventQueue.java:688)
        at java.awt.EventQueue$3.run(EventQueue.java:686)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:697)
        at org.owasp.webscarab.util.swing.TextComponentContextMenu.dispatchEvent(TextComponentContextMenu.java:32)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
Strip "invisible" control characters from log output

The log output is also written to the console where certain characters have
a special meaning. ESC can be used to change colors, BEL rings the bell, DEL
removes the previous character... these side-effects are unwanted, hence remove
it from the log output.
Upgrade Bouncy Castle implementation to 1.48

Prepare for subjectAltName extension.
Copy CN and SAN from server certificate.

Previously, the following happens for a connection setup:
1. Client sends CONNECT example.com:443
2. Server creates a certificate for example.com and gives it to the client.
3. Client continues TLS handshake and sends the actual request, encrypted.
4. Server connects to example.com:443, established a secure connection and
   performs the request. It then writes the response back to the client.

This has generally worked well, but I found an Android client that connects to
an IP address (192.0.2.0:443) and does not use SNI to make clear that it
actually wanted "example.com". Instead, it connects to an IP address and
compares the names on the certificate with a string in the application code.
Since my goal is to make WS as transparant as possible, I changed the order to:
1. Client sends CONNECT 192.0.2.0:443
2. Server reads the following ClientHello from the client and searches for SNI
   server name.
3. Server connects to 192.0.2.0:443, sending the SNI server name if any.
4. Server retrieves certificates from 192.0.2.0:443.
5. Server generates a certificate based on the 192.0.2.0:443 certificate.
6. Server finishes handshake with client.
7. Client sends the actual request, encrypted.
8. Server reuses the connection to 192.0.2.0:443 and performs the request. It
   then writes the response back to the client.

This new approach may introduce slightly more delay since the client TLS
handshake is now completed when the server established a TLS connection with the
requested server. Previously the client could start sending data immediately
after sending the CONNECT line to WS.

Currently, the Subject field and subjectAlternateNames fields are copied from
the original certificate, disregarding the requested host name or IP address.
If the client gets a warning because of a domain name mismatch when connecting
directly, it will now also get that warning when connecting via WS. (It also
means that the above Android client does not complain about the names anymore.)

For that Android client, WS will still use the IP address in the logs though.
(WS cannot know which host name the Android client is comparing to.)

Conflicts:
	src/org/owasp/webscarab/plugin/proxy/ConnectionHandler.java