Re: security/burpsuite MODJAVA_VER

2019-06-03 Thread Ian Darwin

On 6/2/19 10:42 PM, Lawrence Teo wrote:

Thanks. I tried what you suggested:
/usr/local/jdk-11/bin/java -Xms1G -Xmx4G -XX:MaxPermSize=1024M -jar \
  /usr/local/share/java/classes/burpsuite.jar

I got the same result where Firefox showed the Secure Connection Failed
page with error code SSL_ERROR_RX_RECORD_TOO_LONG.

I noticed that the person who posted those -X options in that thread was
using Burp Suite Professional Edition instead of the Community Edition.
According to an Apr 9, 2019 post by Paul Johnston (a Support Center
agent) in that thread:

"The latest versions of Burp Professional have fixes so that Burp
correctly works with the latest Java versions. At the moment there isn't
a Community Edition release with these features."

So it seems like that error is unfortunately related to the Java version
itself.

Do you have other ideas or suggestions on how to overcome this instead
of reverting to jdk 1.8?

No, given that it's a known problem between Burp CE and Java 11, I'd set 
it to 1.8 for the time being.


Thx

Ian




Re: security/burpsuite MODJAVA_VER

2019-06-02 Thread Lawrence Teo
On Sun, Jun 02, 2019 at 08:21:25AM -0400, Ian Darwin wrote:
> On Sat, Jun 01, 2019 at 11:34:30PM -0400, Lawrence Teo wrote:
> > Burp Suite Community Edition needs jdk 1.8 to run properly.  Using it
> > with jdk 11 will show this message on startup:
> > 
> > WARNING: An illegal reflective access operation has occurred
> > WARNING: Illegal reflective access by burp.uie 
> > (file:/usr/local/share/java/classes/burpsuite.jar) to field 
> > javax.crypto.JceSecurity.isRestricted
> > WARNING: Please consider reporting this to the maintainers of burp.uie
> > WARNING: Use --illegal-access=warn to enable warnings of further illegal 
> > reflective access operations
> > WARNING: All illegal access operations will be denied in a future release
> 
> That message is just a warning, appears all over Java land these days, and
> is due to Java 9+ enforcing inter-class security more (if a library author
> wants to expose classes to introspection by client classes, the library has
> to list those classes as 'open' in the library's module info file, in
> addition to the previously-required 'public' specification).  These will get
> cleaned up over time.

Ah, good to know!  Thank you for the insight.

> > In addition, attempting to intercept HTTPS will make the browser show an
> > error code SSL_ERROR_RX_RECORD_TOO_LONG (I tested with Firefox).
> > According to [1], this is due to using the free edition of Burp Suite
> > with jdk 11.
> > 
> > The diff below fixes this by setting MODJAVA_VER to 1.8 which resolves
> > both issues.  While here I have also:
> 
> Before reverting to a relatively old version of Java, did you try
> adding the options shown in the link you cited, e.g -Xms16 -Xms4G 
> -XX:MaxPermSize=1024M?
> Actually that looks a typo, I suspect it was meant to be -Xms1G -Xmx4G
> (these are start and max memory allocation).  I don't have 'burp' installed 
> or I'd d try it.

Thanks.  I tried what you suggested:

/usr/local/jdk-11/bin/java -Xms1G -Xmx4G -XX:MaxPermSize=1024M -jar \
 /usr/local/share/java/classes/burpsuite.jar

I got the same result where Firefox showed the Secure Connection Failed
page with error code SSL_ERROR_RX_RECORD_TOO_LONG.

I noticed that the person who posted those -X options in that thread was
using Burp Suite Professional Edition instead of the Community Edition.
According to an Apr 9, 2019 post by Paul Johnston (a Support Center
agent) in that thread:

"The latest versions of Burp Professional have fixes so that Burp
correctly works with the latest Java versions. At the moment there isn't
a Community Edition release with these features."

So it seems like that error is unfortunately related to the Java version
itself.

Do you have other ideas or suggestions on how to overcome this instead
of reverting to jdk 1.8?



Re: security/burpsuite MODJAVA_VER

2019-06-02 Thread Ian Darwin
On Sat, Jun 01, 2019 at 11:34:30PM -0400, Lawrence Teo wrote:
> Burp Suite Community Edition needs jdk 1.8 to run properly.  Using it
> with jdk 11 will show this message on startup:
> 
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by burp.uie 
> (file:/usr/local/share/java/classes/burpsuite.jar) to field 
> javax.crypto.JceSecurity.isRestricted
> WARNING: Please consider reporting this to the maintainers of burp.uie
> WARNING: Use --illegal-access=warn to enable warnings of further illegal 
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release

That message is just a warning, appears all over Java land these days, and
is due to Java 9+ enforcing inter-class security more (if a library author
wants to expose classes to introspection by client classes, the library has
to list those classes as 'open' in the library's module info file, in
addition to the previously-required 'public' specification).  These will get
cleaned up over time.

> In addition, attempting to intercept HTTPS will make the browser show an
> error code SSL_ERROR_RX_RECORD_TOO_LONG (I tested with Firefox).
> According to [1], this is due to using the free edition of Burp Suite
> with jdk 11.
> 
> The diff below fixes this by setting MODJAVA_VER to 1.8 which resolves
> both issues.  While here I have also:

Before reverting to a relatively old version of Java, did you try
adding the options shown in the link you cited, e.g -Xms16 -Xms4G 
-XX:MaxPermSize=1024M?
Actually that looks a typo, I suspect it was meant to be -Xms1G -Xmx4G
(these are start and max memory allocation).  I don't have 'burp' installed or 
I'd d try it.



security/burpsuite MODJAVA_VER

2019-06-01 Thread Lawrence Teo
Burp Suite Community Edition needs jdk 1.8 to run properly.  Using it
with jdk 11 will show this message on startup:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by burp.uie 
(file:/usr/local/share/java/classes/burpsuite.jar) to field 
javax.crypto.JceSecurity.isRestricted
WARNING: Please consider reporting this to the maintainers of burp.uie
WARNING: Use --illegal-access=warn to enable warnings of further illegal 
reflective access operations
WARNING: All illegal access operations will be denied in a future release
Your JRE appears to be version 11.0.3 from Oracle Corporation
Burp has not been fully tested on this platform and you may experience problems.

In addition, attempting to intercept HTTPS will make the browser show an
error code SSL_ERROR_RX_RECORD_TOO_LONG (I tested with Firefox).
According to [1], this is due to using the free edition of Burp Suite
with jdk 11.

The diff below fixes this by setting MODJAVA_VER to 1.8 which resolves
both issues.  While here I have also:

* Used sthen@'s XXX message about checking if future updates will work
  with jdk 11
* Changed the HOMEPAGE to https
* Switched to the new PERMIT_* markers

ok?

1. 
https://support.portswigger.net/customer/portal/questions/17434431-gettin-error-code-ssl-error-rx-record-too-long



Index: Makefile
===
RCS file: /cvs/ports/security/burpsuite/Makefile,v
retrieving revision 1.26
diff -u -p -r1.26 Makefile
--- Makefile24 Mar 2019 22:24:14 -  1.26
+++ Makefile2 Jun 2019 03:04:52 -
@@ -5,16 +5,16 @@ COMMENT = tool for testing security of 
 VERSION =  1.7.36
 DISTNAME = burpsuite_free_v${VERSION}
 PKGNAME =  burpsuite-${VERSION}
+REVISION = 0
 
 
DISTFILES=${DISTNAME}${EXTRACT_SUFX}{Download?productId=100\=${VERSION}\=Jar}
 
 CATEGORIES =   security
 
-HOMEPAGE = http://portswigger.net/burp/
+HOMEPAGE = https://portswigger.net/burp/
 
-PERMIT_PACKAGE_CDROM=   https://portswigger.net/burp/eula-free.html
-PERMIT_PACKAGE_FTP= https://portswigger.net/burp/eula-free.html
-PERMIT_DISTFILES_FTP=   https://portswigger.net/burp/eula-free.html
+PERMIT_PACKAGE =   https://portswigger.net/burp/eula-free.html
+PERMIT_DISTFILES = https://portswigger.net/burp/eula-free.html
 
 MASTER_SITES = https://portswigger.net/Burp/Releases/
 
@@ -22,7 +22,8 @@ EXTRACT_ONLY =
 EXTRACT_SUFX = .jar
 
 MODULES =  java
-MODJAVA_VER =  1.8+
+# XXX if updating, please check if it works with jdk 11 and switch to "1.8+" 
if ok
+MODJAVA_VER =  1.8
 MODJAVA_JRERUN =   yes
 
 RUN_DEPENDS =  java/javaPathHelper