Jump to content


Photo

Java in the browser...


This topic has been archived. This means that you cannot reply to this topic.
38 replies to this topic

#1 Gavin Chappell

Gavin Chappell
  • Moderators
  • 441 posts

Posted 29 January 2016 - 09:36 AM

EDITED FOR 2018

 

As of the macOS Mojave release, Internet Explorer 11 is now the only browser which still runs Java applets, and must use Oracle Java 8 (Java 9 or above will not work, and nor will OpenJDK Java 8). Customers should be investigating the Standalone SSL VPN Agent as a priority, or making a plan to switch to the CloudGen Firewall.

 

Original post follows....

---

 

As of now, at the start of 2016, Chrome has already removed support for NPAPI plugins, Microsoft Edge never had support, Firefox will be removing support before the end of the year, which leaves Internet Explorer on full versions of Windows (i.e. not the RT/Phone OS) as the only platform with no plans to deprecate Java support.
 
This is further compounded by yesterday's news that Oracle themselves are going to consider in-browser support deprecated as of the release of Java 9: https://blogs.oracle.com/java-platform-group/entry/moving_to_a_plugin_free
 
This will have an effect on users of the Barracuda SSL VPN, however this is mitigated by the inclusion of the Standalone SSL VPN Agent in firmwares newer than 2.6.1.1. This Agent makes a good alternative to relying on browser launching.
 
Some more information on the Standalone Agent is available on the Barracuda Tech Library:
 
https://techlib.barr...onfigStandalone



#2 Nick Urban

Nick Urban
  • Members
  • 7 posts

Posted 09 February 2016 - 11:33 AM

Does Barracuda have any plans to implement a new method of browser launching for the SSL VPN? One of the main reasons I decided to go with Barracuda's VPN solution was the ability for users to launch resources without needing to install any software. This will present a major obstacle for granting clients access, as most are unable to install external software for security reasons. The convenience of launching everything from inside the browser also has a lot of value on its own.



#3 Gavin Chappell

Gavin Chappell
  • Moderators
  • 441 posts

Posted 09 February 2016 - 12:00 PM

There are no plans right now - the standalone agent is our supported solution, it doesn't require admin rights to install, and it's really only the same "external" software that would be downloaded by the browser applet anyway. Almost all of the code is shared between the two agents, the only difference is the way they're launched.

 

Java is the only sensible option for our cross-platform requirements (some other SSL VPN vendors use ActiveX for similar purposes, which will only ever work in IE on Windows computers) so we're really bound by Oracle's behaviour here, and we don't think that there's enough of an advantage over the standalone agent by reworking everything to launch from the browser in a different way.



#4 Robert Czymoch

Robert Czymoch
  • Members
  • 59 posts

Posted 24 February 2016 - 10:36 PM

You need to make the launching of the network connector from the SSL VPN agent to not require admin rights. This may be difficult because it requires the installation of the TAP driver. Perhaps breaking that up into a separate install would be a good idea? Right now the stand alone connector is very buggy. Sometimes it works, sometimes it connects but no traffic can pass, sometimes you are unable to install the client config from the Web portal. Additionally I can find no documentation that explains how to manually install a config file. However it works flawlessly when launching from the SSL VPN agent, your user just needs to be local admin.



#5 Gavin Chappell

Gavin Chappell
  • Moderators
  • 441 posts

Posted 25 February 2016 - 03:12 AM

There's already a "fat" client that can be installed as a standalone client (i.e. doesn't require the SSL VPN Agent at all) which needs admin rights at install time (for the TAP driver, as you say) but does not require admin rights at run time.

 

We're aware of issues on some machines which we haven't been able to reproduce in-house, primarily with Windows 8 and 10, whereby the connection seems to come up but without a valid IP address, and without adding routes. This is already in our bug tracker. I believe our Support team have had success with installing the latest TAP drivers available with something like OpenVPN in this instance, they may be able to help you more. The standalone Network Connector and the Network Connector launched via the Agent use the same version of the TAP driver, and it only gets installed once, so I can't think of any way that one method should be more reliable than the other, but that's good feedback.

 

We can't make Agent-launched Network Connector run without admin rights unfortunately because these rights are needed to add network routes to the system's routing table - the standalone client works around this by having a service running as SYSTEM in order to do that on the user's behalf, but this is not possible with the Agent client since this is designed to be portable and not require any installation



#6 bad-wurzach

bad-wurzach
  • Members
  • 19 posts

Posted 28 February 2016 - 10:59 AM

Java is the only sensible option for our cross-platform requirements (some other SSL VPN vendors use ActiveX for similar purposes, which will only ever work in IE on Windows computers) so we're really bound by Oracle's behaviour here, and we don't think that there's enough of an advantage over the standalone agent by reworking everything to launch from the browser in a different way.

Is a HTML5 no option at this time? All 4 weeks a new java security vulnerability... for years. Regardless, it is a safety issue for home offices. the employee must keep Java up to date. That's often a Challenge for our helpdesk but also for the user...

 

Does Barracuda have any plans to implement a new method of browser launching for the SSL VPN? One of the main reasons I decided to go with Barracuda's VPN solution was the ability for users to launch resources without needing to install any software. This will present a major obstacle for granting clients access, as most are unable to install external software for security reasons. The convenience of launching everything from inside the browser also has a lot of value on its own.

We also.



#7 Gavin Chappell

Gavin Chappell
  • Moderators
  • 441 posts

Posted 09 March 2016 - 03:01 PM

HTML 5 may be a solution for a small subset of the functionality provided by the agent - there are a couple of HTML 5 RDP+SSH solutions which we looked at integrating. One is open-source and got to the "tech demo" stage, but was found to be unscalable for more than one or two connections, one was a commercial library but I think we were unable to reach a suitable deal. Bear in mind this also wouldn't cover NAC checking, SSL tunnels, certain types of web forwards, etc so while it may be suitable for some customers it doesn't fulfill everything the agent does, as I explained above.
 
The standalone agent contains its own JRE (which is NOT accessible from within the browser, and therefore doesn't pose the same security risks from drive-by malware or similar), and can be installed by non-administrative users purely into their user profile without making any modifications on the operating system level.


#8 Gavin Chappell

Gavin Chappell
  • Moderators
  • 441 posts

Posted 25 July 2016 - 07:36 AM

More updates on this - it seems that in macOS Sierra (which ships with Safari 10), Unsafe Mode is no longer available for plugins running in Safari. This means that the browser-based agent will not run in Safari on macOS Sierra, although it still works (for now) with Firefox.

 

Please be aware of this before upgrading any Macs if this functionality is important to you, and familiarise yourself with the Standalone Agent documentation as this will likely be the only method available soon (as Chrome has already removed support for plugins).

 

edit 31/10/2016 - Safari 10 still supports Java, however the instructions for disabling Safe Mode have changed slightly. Our Campus article is up to date as of the release of Sierra.



#9 Gavin Chappell

Gavin Chappell
  • Moderators
  • 441 posts

Posted 06 March 2017 - 03:07 PM

It arrived a bit later than expected, but as of Firefox 52, Java support in the browser has been removed. This leaves IE 11 (Windows) and Safari (OSX/macOS) as the only browsers which can use the web-launched SSL VPN Agent, all other browsers will need to be used alongside the Standalone Agent.



#10 Bud Gifford

Bud Gifford
  • Members
  • 18 posts

Posted 10 May 2017 - 07:50 AM

Since almost all browsers are or have already de-supported Java I am finding great need for the SSL VPN to work fully without Java being a requirement.

 

Here is our problem.  We bought the SSL VPN for ease of use by our remote users who are mostly persons that have difficulty with computer use.  The SSL VPN makes that easy for them.  It is easy for them to use the "Network Connector" and be on our network to use tools normally only available from being directly on our network. They generally do not have the skills to set up he stand alone agent and many are not locally located for us to do it for them.  So, we are becoming severely diabed.  Other than them using IE or some old browser that still supports Java which is a bit of a security issue.  So we are hoping for a fix for the SSL VPN as we do not have the $$ for a NextGen Firewall.  That is even if the NextGen Firewall has SSL VPN access.  If the NextGen Firewall does support this, can the SSL VPN be traded in for the NextGen Firewall? 

 

So, whe you say development on the SSL VPN has been halted, are you saying it is being de-supported and is at end of life?  If so we can start shopping for another brand that will be able to replace it with the SSL VPN feature that we need. One that we can hopefully afford without buying a full blow firewall.  Unless full credit is give on the SSL VPN by Barracuda toward the firewall purchase.

 

This is putting us between a big rock and very hard, hard place.



#11 sorin

sorin
  • Members
  • 52 posts

Posted 15 May 2017 - 02:08 AM

We payed for the continuus development of the SSL VPN and now it is kind of strange to here that Barracuda has no intention to develop it any further.

This is kind of shaking the trust that we have in Barracuda Networks.

We need a full commitment from Barracuda that will implement non Java tools in order for the SSL VPN to keep with the market.



#12 sorin

sorin
  • Members
  • 52 posts

Posted 15 May 2017 - 02:25 AM

  • Chrome no longer supports java applets
  • Firefox is about to drop java applet support:
  • The new Microsoft Edge Browser (for Windows 10) does not support java applets
  • Java Applets are of course also a major security risk.

 

taking into consideration the above, and the fact that barracuda networks is not coomited to develop any further the SSL VPN we are all forced to migrate to NEXT GENERATION FIREWALL or to other products on the market. However, since we have payed already in advance for development of SSL VPN, it is my personal understanding that we should receive some financiar compensations or updated to NEXT GEN FIREWALL.

 

​There is a big matter of trust in Barracuda Networks on my side since two years ago you have left us with the impression that the SSL VPN solution will migrate from Java to HTML5. However untill now there is no result towards that objective but contrarry we are announced that you drop the further development of the SSL VPN.



#13 Gavin Chappell

Gavin Chappell
  • Moderators
  • 441 posts

Posted 15 May 2017 - 04:35 AM

"HTML5" itself is not a feature, it is just a new way of presenting the other features of the SSL VPN. Features that the Java Agent provides include:

 

* Application launching such as RDP

* Tunnelled web proxies include DNS interception

* Fully-featured Network Access Control

* Standalone SSL Tunnels

* Remote Assistance on larger boxes

 

The only one of these features that could be replaced with an HTML5 presentation layer is RDP - which we tested, found that it didn't scale well enough, and did not release. We tried two different HTML5 RDP solutions, one open-source and one commercial library. The open-source worked "OK", but as is often the case with open-source, it depended on various other components and was a considerable effort to implement. The commercial solution was very expensive because it offered a lot of unneeded features. Neither of these solutions scaled well and even an expensive 680-series appliance could not handle even tens of RDP sessions, meaning that the HTML5 RDP feature would have offered poor value for money to customers.

 

I don't believe any release date was ever promised for HTML5 RDP - it has been said several times on this forum that it was under investigation, which it was. But it was unfeasible to actually release it as a feature and so we didn't.



#14 sorin

sorin
  • Members
  • 52 posts

Posted 15 May 2017 - 07:28 AM

True HTML5 is not a feature is a possible way to make the SSL VPN features to work.

But then if SSL VPN will work with no browser I would then be tempted to conclude that it is an obsolite product and then my qwestion is why do we pay for firmware updates if there will be none.



#15 Gavin Chappell

Gavin Chappell
  • Moderators
  • 441 posts

Posted 15 May 2017 - 07:53 AM

True HTML5 is not a feature is a possible way to make the SSL VPN features to work.

It is a possible way to make one SSL VPN feature (RDP) work. However it is not a solution to all SSL VPN features that require the SSL VPN Agent.

 

Customers do not pay specifically for firmware updates, they subscribe to the Energize Update service as a whole. This may include firmware updates, but equally is not guaranteed to. On the SSL VPN this service is primarily for updates to the Network Access Control subsystem which is still going to be maintained while the product is in maintenance mode.

 

The SSL VPN is primarily an authenticating reverse proxy, which has never required Java. If your personal use case is mostly based around RDP and other SSL Tunnels then you would likely be better served by an NG Firewall with CudaLaunch and/or a full TINA VPN connection (which provide better security than Network Connector because there is firewalling capabilities that Network Connector does not have). However we also have many customers who only need the web-based features and are not affected by the Java limitations in this thread. The product cannot be judged as obselete based only on your opinion - maybe your needs have changed and it is no longer the right product for you, but this is not the same as becoming obsolete.



#16 sorin

sorin
  • Members
  • 52 posts

Posted 15 May 2017 - 08:50 AM

My needs are the same as two years ago.

It is just that the market evolved and the SSL VPN appliance does not keep with the market as expected by me.

Since Java soon will not be supported by the main web browsers then the SSL VPN cannot be used either.

Without Java the SSL VPN tunnels cannot be established so why do you insist the product can be used?

 

​If I would like to use a feature like certificate autentification in Edge it does not work because of Java. It used to work when I purchased the appliance. The screen freezes and I can not even return to insert the name of another user.

 

Also none of the SSL VPN Applications works. At least non of the ones I have. Are you able to use any of them?

The SSL Tunnels does not work either.

 Network connector does not work without java.

IPsec server does not work without java.

 

So what are the services that remains?

Should the product name be SSL VNP or just the The web forwarder?

 

Do you believe that we can see the SSL VPN as a functional product in such circumstances?

​Do you agree with a general understanding that if you receive some money for a product you should provide a product that works?

​At this time the SSL VPN does not work any longer and because of that it is my understanding that Barracuda Networks either makes it work either replace the appliance.



#17 sorin

sorin
  • Members
  • 52 posts

Posted 15 May 2017 - 09:15 AM

Same here.  We demo'd the unit and bought it for certain uses.  And we have only had it a short time. And then Barracuda saying they were going to develop it and get it working "after" Java was accepted. And in fact we do pay monthly fees for these things to be maintained, developed, and keep up with the times. And it is disappointing that Barracuda, know as the best in the industry for customer support, did not bother to notify anyone that any of this was going to happen.  It just did.  It stopped doing what needed with no warning of "it will bever work the same again", and "we are not going to try to make it work ever again".  This is so unlike Barracuda.  And we literally own all but one of Barracuda's products and this is the first time we have seen them drop the ball so badly.  Hope this is not the norm for the future.

 

from

https://community.ba...ife-in-essence/



#18 Gavin Chappell

Gavin Chappell
  • Moderators
  • 441 posts

Posted 15 May 2017 - 09:33 AM

My needs are the same as two years ago.
It is just that the market evolved and the SSL VPN appliance does not keep with the market as expected by me.


I have bolded the relevant part of your statement - your needs do not describe all of our customers' needs.
 

Since Java soon will not be supported by the main web browsers then the SSL VPN cannot be used either.
Without Java the SSL VPN tunnels cannot be established so why do you insist the product can be used?


SSL Tunnels are not the only feature of the product, nor are they the main feature. The SSL VPN's primary feature is Web Forwards, which can be used without the SSL VPN Agent in almost all cases. As I said, your needs are not the same as all customers needs. Many customers only need Web Forwards and are therefore perfectly happy with Java-less functionality. And for those that do need the agent, there is the Standalone Agent (link in the first post) which meets all of the Agent needs without having the Java browser plugin available.
 

If I would like to use a feature like certificate autentification in Edge it does not work because of Java. It used to work when I purchased the appliance. The screen freezes and I can not even return to insert the name of another user.


You should open a Support case about this - client certificate authentication does not require Java, it only requires support for client certificates in the browser, which Edge does have. Edge has never had support for Java applets, so if you say this used to work then you have proven that this feature is not Java-based and that you have a different issue here.
 

Also none of the SSL VPN Applications works. At least non of the ones I have. Are you able to use any of them?
The SSL Tunnels does not work either.


This is correct, this feature requires the Agent, which is available as a standalone app. This app continues working without Java support in the browser.
 

Network connector does not work without java.
IPsec server does not work without java.


These two are not correct, both of these features can be used without Java. Network Connector has a standalone client, IPsec simply configures the client which is built into Windows/OSX, therefore these clients can be configured by any other means and still work fine with the SSL VPN.
 

Do you believe that we can see the SSL VPN as a functional product in such circumstances?
​Do you agree with a general understanding that if you receive some money for a product you should provide a product that works?


I do agree, and our product still works. There may be some minor changes caused by events outside of Barracuda's control (i.e. you will likely have to replace the applet-launched Agent with the standalone Agent, which has an identical workflow once running) but the product is just as functional today as it ever was.

I think by now we've probably had all the useful discussion that can come out of this - at this point, if you are unhappy with the continued functionality of your SSL VPN appliance then I would suggest speaking to our Sales team and discussing a migration to a NextGen Firewall (obviously we could provide you with a trial VM for you to verify the functionality first before purchase). They may be able to do something with the price based on your SSL VPN subscription status, but that is entirely up to the Sales team and I can't promise any discount.

#19 Bud Gifford

Bud Gifford
  • Members
  • 18 posts

Posted 15 May 2017 - 11:12 AM

A lot is getting hashed around about HTML 5 not being the answer.  Yes I did bring that up because of my limited Dev knowledge and reading forums online.  No, I am not a Dev.  So, I do not know a solution and what components do and do not work in what ways and with what technology (Java/HTML 5/flash/whatever).  I am just saying, that we got the product to do what it did best, which was via a quick easy to use web-browser-based platform for our non-technical users.  And a lot of those features are now not easily usable by them via a simple web browser interface.  Our users loved the product and everyone could easily use it by going to a web page, logging in, and just click on what they needed.  That is now impaired and has become more complicated for them and I am just saying that I am disappointed that I am hearing it will remain that way - and all that information came via googling it as opposed to being notified by Barracuda at all or at least far enough in advance to make plans to find a replacement option.  Or to budget for a replacement option.  Like I say, I love Barracuda, and their support has been the best of the best.  Except for this instance - it has been quite a disappointment.



#20 sorin

sorin
  • Members
  • 52 posts

Posted 16 May 2017 - 03:36 AM

Goo Lord Gavin !

If the SSL Tunnels are not ”the main feature. The SSL VPN's primary feature is Web Forwards” why did Barracuda Networks advertised this product as a VPN SSL and not as a Web Forwarder? Do not have to answer the above just a silly qwestion in my mind.

 

Your answer is true regarding certificate authentification

My mistake, I whanted to point towards Authentification Keys

 

Can you please point me towards a tutorial to launch a RDP app or other Application using the Agent standalone app?

 

Network Connector has a standalone client​. True, but can you run that without the administrative credentials?

”which has an identical workflow” - NOT AT ALL. As long as you need administrator credential then you will restrict dramatically the number of the machines that can use the servce only to those you are administrating.

For example in this particular case When it will be solved this bug? It is a feature that the appliance should have but does not work?

 

”IPsec simply configures the client which is built into Windows/OSX”

To do that we can use a dam router with IPsec at 20$ not KKK$ Barracuda SSL VPN

The feature sold to us was suposed to perform an automatic opening of the tunnels without IT department configuring all the client devices.