You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@guacamole.apache.org by Jason Keltz <ja...@yorku.ca> on 2022/01/03 16:18:27 UTC
TLSv1.3 requirement in guac 1.4.0?
Hi..
I tried to bring install Guac 1.4.0 into place on our CentOS 7 server
running 1.3.0. I kept getting "invalid user" for logins. After some
debugging, I see in the logs (included below in more detail) an
exception caused by "Caused by: java.lang.IllegalArgumentException:
TLSv1.3". I believe there is an attempt to connect to the LDAP server
with TLS 1.3, and when that fails, the auth fails as well, where-as
previously TLS 1.2 would have been used. I may be wrong.
The identical configuration works with 1.3.
Is something requiring TLS v1.3 now that previously worked with 1.2?
(names/IPs changed)
Additional logs below..
> 10:27:47.806 [http-nio-8080-exec-1] DEBUG
> o.a.g.a.ldap.LDAPConnectionService - Connecting to LDAP server using
> SSL/TLS.
> 10:27:47.867 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.c.o.DefaultLdapCodecService -
> MSG_06000_REGISTERED_CONTROL_FACTORY (1.3.6.1.4.1.18060.0.0.1)
> 10:27:47.868 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.c.o.DefaultLdapCodecService -
> MSG_06000_REGISTERED_CONTROL_FACTORY (2.16.840.1.113730.3.4.7)
> 10:27:47.868 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.c.o.DefaultLdapCodecService -
> MSG_06000_REGISTERED_CONTROL_FACTORY (2.16.840.1.113730.3.4.2)
> 10:27:47.869 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.c.o.DefaultLdapCodecService -
> MSG_06000_REGISTERED_CONTROL_FACTORY (1.2.840.113556.1.4.319)
> 10:27:47.869 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.c.o.DefaultLdapCodecService -
> MSG_06000_REGISTERED_CONTROL_FACTORY (2.16.840.1.113730.3.4.3)
> 10:27:47.870 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.c.o.DefaultLdapCodecService -
> MSG_06000_REGISTERED_CONTROL_FACTORY (2.16.840.1.113730.3.4.18)
> 10:27:47.870 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.c.o.DefaultLdapCodecService -
> MSG_06000_REGISTERED_CONTROL_FACTORY (1.2.840.113556.1.4.473)
> 10:27:47.871 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.c.o.DefaultLdapCodecService -
> MSG_06000_REGISTERED_CONTROL_FACTORY (1.2.840.113556.1.4.474)
> 10:27:47.871 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.c.o.DefaultLdapCodecService -
> MSG_06000_REGISTERED_CONTROL_FACTORY (1.3.6.1.4.1.4203.1.10.1)
> 10:27:47.872 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.c.StockCodecFactoryUtil -
> MSG_06000_REGISTERED_CONTROL_FACTORY (1.3.6.1.4.1.18060.0.0.1)
> 10:27:47.872 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.c.StockCodecFactoryUtil -
> MSG_06000_REGISTERED_CONTROL_FACTORY (2.16.840.1.113730.3.4.7)
> 10:27:47.872 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.c.StockCodecFactoryUtil -
> MSG_06000_REGISTERED_CONTROL_FACTORY (2.16.840.1.113730.3.4.2)
> 10:27:47.872 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.c.StockCodecFactoryUtil -
> MSG_06000_REGISTERED_CONTROL_FACTORY (1.2.840.113556.1.4.319)
> 10:27:47.872 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.c.StockCodecFactoryUtil -
> MSG_06000_REGISTERED_CONTROL_FACTORY (2.16.840.1.113730.3.4.3)
> 10:27:47.872 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.c.StockCodecFactoryUtil -
> MSG_06000_REGISTERED_CONTROL_FACTORY (2.16.840.1.113730.3.4.18)
> 10:27:47.872 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.c.StockCodecFactoryUtil -
> MSG_06000_REGISTERED_CONTROL_FACTORY (1.2.840.113556.1.4.473)
> 10:27:47.872 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.c.StockCodecFactoryUtil -
> MSG_06000_REGISTERED_CONTROL_FACTORY (1.2.840.113556.1.4.474)
> 10:27:47.872 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.c.StockCodecFactoryUtil -
> MSG_06000_REGISTERED_CONTROL_FACTORY (1.3.6.1.4.1.4203.1.10.1)
> 10:27:47.873 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06000_REGISTERED_CONTROL_FACTORY (1.2.840.113556.1.4.841)
> 10:27:47.874 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06000_REGISTERED_CONTROL_FACTORY (1.2.840.113556.1.4.841)
> 10:27:47.874 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06000_REGISTERED_CONTROL_FACTORY (1.2.840.113556.1.4.2239)
> 10:27:47.875 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06000_REGISTERED_CONTROL_FACTORY (1.2.840.113556.1.4.417)
> 10:27:47.875 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06000_REGISTERED_CONTROL_FACTORY (1.2.840.113556.1.4.528)
> 10:27:47.876 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06000_REGISTERED_CONTROL_FACTORY (2.16.840.1.113730.3.4.4)
> 10:27:47.876 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06000_REGISTERED_CONTROL_FACTORY (1.3.6.1.4.1.42.2.27.8.5.1)
> 10:27:47.877 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06000_REGISTERED_CONTROL_FACTORY (1.3.6.1.4.1.42.2.27.8.5.1)
> 10:27:47.877 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06000_REGISTERED_CONTROL_FACTORY (1.2.840.113556.1.4.1413)
> 10:27:47.877 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06000_REGISTERED_CONTROL_FACTORY (1.3.6.1.4.1.4203.1.9.1.3)
> 10:27:47.878 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06000_REGISTERED_CONTROL_FACTORY (1.3.6.1.4.1.4203.1.9.1.1)
> 10:27:47.878 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06000_REGISTERED_CONTROL_FACTORY (1.3.6.1.4.1.4203.1.9.1.2)
> 10:27:47.878 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06000_REGISTERED_CONTROL_FACTORY (1.3.6.1.1.21.2)
> 10:27:47.879 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06000_REGISTERED_CONTROL_FACTORY (2.16.840.1.113730.3.4.9)
> 10:27:47.879 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06000_REGISTERED_CONTROL_FACTORY (2.16.840.1.113730.3.4.10)
> 10:27:47.879 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06000_REGISTERED_CONTROL_FACTORY (1.3.6.1.4.1.4203.666.5.12)
> 10:27:47.880 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06001_REGISTERED_EXTENDED_OP_FACTORY (1.3.6.1.1.8)
> 10:27:47.881 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06001_REGISTERED_EXTENDED_OP_FACTORY (1.3.6.1.4.1.18060.0.1.8)
> 10:27:47.882 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06001_REGISTERED_EXTENDED_OP_FACTORY (1.3.6.1.1.21.3)
> 10:27:47.883 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06001_REGISTERED_EXTENDED_OP_FACTORY (1.3.6.1.4.1.18060.0.1.5)
> 10:27:47.883 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06001_REGISTERED_EXTENDED_OP_FACTORY (1.3.6.1.4.1.18060.0.1.3)
> 10:27:47.883 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06001_REGISTERED_EXTENDED_OP_FACTORY (1.3.6.1.4.1.1466.20036)
> 10:27:47.884 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06001_REGISTERED_EXTENDED_OP_FACTORY (1.3.6.1.4.1.4203.1.11.1)
> 10:27:47.885 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06001_REGISTERED_EXTENDED_OP_FACTORY (1.3.6.1.4.1.1466.20037)
> 10:27:47.886 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06001_REGISTERED_EXTENDED_OP_FACTORY (1.3.6.1.1.21.1)
> 10:27:47.886 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06001_REGISTERED_EXTENDED_OP_FACTORY (1.3.6.1.4.1.18060.0.1.6)
> 10:27:47.887 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06001_REGISTERED_EXTENDED_OP_FACTORY (1.3.6.1.4.1.4203.1.11.3)
> 10:27:47.888 [http-nio-8080-exec-1] INFO
> o.a.d.a.l.e.ExtrasCodecFactoryUtil -
> MSG_06002_REGISTERED_INTERMEDIATE_FACTORY (1.3.6.1.4.1.4203.1.9.1.4)
> 10:27:47.896 [http-nio-8080-exec-1] DEBUG
> o.a.d.l.c.api.LdapNetworkConnection - MSG_04112_BIND ()
> 10:27:47.985 [NioProcessor-1] DEBUG
> org.apache.mina.filter.ssl.SslFilter - Adding the SSL Filter sslFilter
> to the chain
> 10:27:47.987 [NioProcessor-1] DEBUG
> o.apache.mina.filter.ssl.SslHandler - Session Client[1](no sslEngine)
> Initializing the SSL Handler
> 1*0:27:47.996 [NioProcessor-1] WARN o.a.m.util.DefaultExceptionMonitor
> - Unexpected exception.**
> **org.apache.mina.core.filterchain.IoFilterLifeCycleException:
> onPreAdd(): sslFilter:SslFilter in (0x00000001: nio socket, client,
> /1.2.3.4:44642 => myldap.yorku.ca/1.2.3.4:636)**
> ** at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.register(DefaultIoFilterChain.java:465)**
> ** at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.addLast(DefaultIoFilterChain.java:234)**
> ** at
> org.apache.mina.core.filterchain.DefaultIoFilterChainBuilder.buildFilterChain(DefaultIoFilterChainBuilder.java:553)**
> ** at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.addNow(AbstractPollingIoProcessor.java:832)**
> ** at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.handleNewSessions(AbstractPollingIoProcessor.java:752)**
> ** at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:652)**
> ** at
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)**
> ** at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)**
> ** at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)**
> ** at java.lang.Thread.run(Thread.java:748)**
> **Caused by: java.lang.IllegalArgumentException: TLSv1.3**
> * at
> sun.security.ssl.ProtocolVersion.valueOf(ProtocolVersion.java:187)
> at sun.security.ssl.ProtocolList.convert(ProtocolList.java:84)
> at sun.security.ssl.ProtocolList.<init>(ProtocolList.java:52)
> at
> sun.security.ssl.SSLEngineImpl.setEnabledProtocols(SSLEngineImpl.java:2070)
> at org.apache.mina.filter.ssl.SslHandler.init(SslHandler.java:177)
> at
> org.apache.mina.filter.ssl.SslFilter.onPreAdd(SslFilter.java:458)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.register(DefaultIoFilterChain.java:463)
> ... 9 common frames omitted
> 10:28:18.005 [http-nio-8080-exec-1] DEBUG
> o.a.d.l.c.api.LdapNetworkConnection - MSG_04177_CONNECTION_TIMEOUT (30000)
> 10:28:18.007 [http-nio-8080-exec-1] ERROR
> o.a.g.a.ldap.LDAPConnectionService - Binding with the LDAP server at
> "myldap.yorku.ca" as user
> "CN=guacamole,CN=Users,DC=ad,DC=eecs,DC=yorku,DC=ca" failed:
> MSG_04177_CONNECTION_TIMEOUT (30000)
> 10:28:18.007 [http-nio-8080-exec-1] DEBUG
> o.a.g.a.ldap.LDAPConnectionService - Unable to bind to LDAP server.
> org.apache.directory.ldap.client.api.exception.LdapConnectionTimeOutException:
> MSG_04177_CONNECTION_TIMEOUT (30000)
Jason.
Re: TLSv1.3 requirement in guac 1.4.0?
Posted by Lukáš Raška <lu...@raska.me>.
Hi,
thanks, so the used version in this case is Java 8u202. The StackOverflow
post seems to indicate that update version 262+ should support TLSv1.3, but
I haven't tested it myself. The upgrade to Java 17 might not be very
straightforward - there were many changes in between (and especially some
breaking changes in Java 17), which would probably require upgrade to all
additional components (Tomcat or other application server, configuration
and JVM flags).
I haven't really tried standard Guacamole version on top of Java 17, as
we're embedding guacamole-common in our project, but I will try to see what
might be needed. Java 11 might be good choice in this case - it's
long-term-support (LTS) version and a lot of changes that happened were
usually backwards compatible. Given that the application server is new
enough to have notion of Java 11.
Otherwise update to newest Java 8 build is probably be something that
should be least problematic. But given that it's out of general support by
Oracle (and Premier supports ends in 2 months -
https://www.oracle.com/java/technologies/java-se-support-roadmap.html ),
you would need to use some alternative build (Adoptium - formerly
AdoptOpenJDK / Amazon Corretto / Azul OpenJDK).
So in case you want to play with this, there are options you can try. As
well as Nick's proposed ability to configure the exact TLS version used.
Lukas
út 4. 1. 2022 v 1:07 odesílatel Jason Keltz <ja...@yorku.ca> napsal:
> Hi Lukáš,
>
> I'm actually using exactly jdk-1.8.0_202 which is the same version of JDK
> I was using back when I started with Guacamole 1.2.0. I tried to upgrade
> to jdk17-17.0.1 at one point recently with 1.3.0, and got many errors, so I
> just went back to jdk-1.8.0. I never did try jdk11. I'm completely
> flexible in this respect, and would want to use the best JDK for the job,
> but I realize I don't know what that is. I'm running Tomcat 9.0.56. I
> know that Nick created a patch to allow the older TLS support, which does
> make sense, and I have to try it when the server isn't in use, but maybe if
> I was using the "best" version of JDK for Guacamole, this might not even be
> necessary. Thoughts, Nick?
>
> Jason.
> On 1/3/2022 5:00 PM, Lukáš Raška wrote:
>
> Hi Jason,
> just curious, what is the exact Java version (including the minor version)
> you're using in this environment? The stacktrace doesn't reveal that the
> TLSv1.3 connection would fail, rather that the support for TLSv1.3 is
> missing completely (as the exception gets thrown at
> sun.security.ssl.ProtocolVersion.valueOf(ProtocolVersion.java:187) ). That
> TLS version should be supported since Java 11 (AFAIK), but seems to be
> backported to certain builds of Java 8 as well (
> https://stackoverflow.com/questions/29437596/tlsv1-3-is-it-available-now-in-java-8
> ).
>
>
> So the solution might be just to upgrade Java to a newer version. I
> couldn't find any notion of required Java version in Guacamole docs, so
> might be worth to mention it there as well (as in general only TLSv1.2+ is
> recommended), in case it's not possible to work without TLSv1.3 support.
>
>
>
>
> Lukas
>
> po 3. 1. 2022 v 18:51 odesílatel Jason Keltz <ja...@yorku.ca> napsal:
>
>>
>> On 1/3/2022 11:45 AM, Nick Couchman wrote:
>>
>> On Mon, Jan 3, 2022 at 11:18 AM Jason Keltz <ja...@yorku.ca> wrote:
>>
>>> Hi..
>>>
>>> I tried to bring install Guac 1.4.0 into place on our CentOS 7 server
>>> running 1.3.0. I kept getting "invalid user" for logins. After some
>>> debugging, I see in the logs (included below in more detail) an exception
>>> caused by "Caused by: java.lang.IllegalArgumentException: TLSv1.3". I
>>> believe there is an attempt to connect to the LDAP server with TLS 1.3, and
>>> when that fails, the auth fails as well, where-as previously TLS 1.2 would
>>> have been used. I may be wrong.
>>>
>>> The identical configuration works with 1.3.
>>>
>>> Is something requiring TLS v1.3 now that previously worked with 1.2?
>>>
>> We updated the dependencies for just about everything, including the
>> Apache Directory API. The latest version of the Apache LDAP API defaults to
>> TLSv1.3:
>>
>>
>> - [DIRAPI-375]https://issues.apache.org/jira/browse/DIRAPI-375) - Add
>> TLSv1.3 to default protocols
>>
>> I suspect this is what you're seeing. You can continue to use the 1.3
>> LDAP extension with Guacamole Client 1.4.0, so that'll work around it for
>> now; however, looks like we may need to find a way to make this
>> configurable. You're welcome to open a Jira issue for it - I'm sure adding
>> an option for TLS version will be reasonably straight-forward.
>>
>> Thanks, Nick. Happy New Year, by the way!
>>
>> I opened up an issue and quoted your response there in case someone else
>> has the same issue: https://issues.apache.org/jira/browse/GUACAMOLE-1488
>>
>> I'll try the 1.3 module if I get the server dead enough to try again...
>> (had to revert from 1.4 back to 1.3 earlier). if you know of the line to
>> change to just hard-code TLS 1.2 for the moment in the 1.4 ldap module, I
>> can try that as well.
>>
>> Jason.
>>
>>
>>
>
> --
> S pozdravem
>
> Lukáš Raška
>
>
Re: TLSv1.3 requirement in guac 1.4.0?
Posted by Jason Keltz <ja...@yorku.ca>.
Hi Lukáš,
I'm actually using exactly jdk-1.8.0_202 which is the same version of
JDK I was using back when I started with Guacamole 1.2.0. I tried to
upgrade to jdk17-17.0.1 at one point recently with 1.3.0, and got many
errors, so I just went back to jdk-1.8.0. I never did try jdk11. I'm
completely flexible in this respect, and would want to use the best JDK
for the job, but I realize I don't know what that is. I'm running
Tomcat 9.0.56. I know that Nick created a patch to allow the older TLS
support, which does make sense, and I have to try it when the server
isn't in use, but maybe if I was using the "best" version of JDK for
Guacamole, this might not even be necessary. Thoughts, Nick?
Jason.
On 1/3/2022 5:00 PM, Lukáš Raška wrote:
> Hi Jason,
> just curious, what is the exact Java version (including the minor
> version) you're using in this environment? The stacktrace doesn't
> reveal that the TLSv1.3 connection would fail, rather that the support
> for TLSv1.3 is missing completely (as the exception gets thrown at
> sun.security.ssl.ProtocolVersion.valueOf(ProtocolVersion.java:187) ).
> That TLS version should be supported since Java 11 (AFAIK), but seems
> to be backported to certain builds of Java 8 as well
> (https://stackoverflow.com/questions/29437596/tlsv1-3-is-it-available-now-in-java-8
> ).
>
>
> So the solution might be just to upgrade Java to a newer version. I
> couldn't find any notion of required Java version in Guacamole docs,
> so might be worth to mention it there as well (as in general only
> TLSv1.2+ is recommended), in case it's not possible to work without
> TLSv1.3 support.
>
>
>
>
> Lukas
>
> po 3. 1. 2022 v 18:51 odesílatel Jason Keltz <ja...@yorku.ca> napsal:
>
>
> On 1/3/2022 11:45 AM, Nick Couchman wrote:
>> On Mon, Jan 3, 2022 at 11:18 AM Jason Keltz <ja...@yorku.ca> wrote:
>>
>> Hi..
>>
>> I tried to bring install Guac 1.4.0 into place on our CentOS
>> 7 server running 1.3.0. I kept getting "invalid user" for
>> logins. After some debugging, I see in the logs (included
>> below in more detail) an exception caused by "Caused by:
>> java.lang.IllegalArgumentException: TLSv1.3". I believe
>> there is an attempt to connect to the LDAP server with TLS
>> 1.3, and when that fails, the auth fails as well, where-as
>> previously TLS 1.2 would have been used. I may be wrong.
>>
>> The identical configuration works with 1.3.
>>
>> Is something requiring TLS v1.3 now that previously worked
>> with 1.2?
>>
>> We updated the dependencies for just about everything, including
>> the Apache Directory API. The latest version of the Apache LDAP
>> API defaults to TLSv1.3:
>>
>> * [DIRAPI-375]https://issues.apache.org/jira/browse/DIRAPI-375)
>> - Add TLSv1.3 to default protocols
>>
>> I suspect this is what you're seeing. You can continue to use the
>> 1.3 LDAP extension with Guacamole Client 1.4.0, so that'll work
>> around it for now; however, looks like we may need to find a way
>> to make this configurable. You're welcome to open a Jira issue
>> for it - I'm sure adding an option for TLS version will be
>> reasonably straight-forward.
>>
> Thanks, Nick. Happy New Year, by the way!
>
> I opened up an issue and quoted your response there in case
> someone else has the same issue:
> https://issues.apache.org/jira/browse/GUACAMOLE-1488
>
> I'll try the 1.3 module if I get the server dead enough to try
> again... (had to revert from 1.4 back to 1.3 earlier). if you
> know of the line to change to just hard-code TLS 1.2 for the
> moment in the 1.4 ldap module, I can try that as well.
>
> Jason.
>
>
>
>
> --
> S pozdravem
>
> Lukáš Raška
Re: TLSv1.3 requirement in guac 1.4.0?
Posted by Lukáš Raška <lu...@raska.me>.
Hi Jason,
just curious, what is the exact Java version (including the minor version)
you're using in this environment? The stacktrace doesn't reveal that the
TLSv1.3 connection would fail, rather that the support for TLSv1.3 is
missing completely (as the exception gets thrown at
sun.security.ssl.ProtocolVersion.valueOf(ProtocolVersion.java:187) ). That
TLS version should be supported since Java 11 (AFAIK), but seems to be
backported to certain builds of Java 8 as well (
https://stackoverflow.com/questions/29437596/tlsv1-3-is-it-available-now-in-java-8
).
So the solution might be just to upgrade Java to a newer version. I
couldn't find any notion of required Java version in Guacamole docs, so
might be worth to mention it there as well (as in general only TLSv1.2+ is
recommended), in case it's not possible to work without TLSv1.3 support.
Lukas
po 3. 1. 2022 v 18:51 odesílatel Jason Keltz <ja...@yorku.ca> napsal:
>
> On 1/3/2022 11:45 AM, Nick Couchman wrote:
>
> On Mon, Jan 3, 2022 at 11:18 AM Jason Keltz <ja...@yorku.ca> wrote:
>
>> Hi..
>>
>> I tried to bring install Guac 1.4.0 into place on our CentOS 7 server
>> running 1.3.0. I kept getting "invalid user" for logins. After some
>> debugging, I see in the logs (included below in more detail) an exception
>> caused by "Caused by: java.lang.IllegalArgumentException: TLSv1.3". I
>> believe there is an attempt to connect to the LDAP server with TLS 1.3, and
>> when that fails, the auth fails as well, where-as previously TLS 1.2 would
>> have been used. I may be wrong.
>>
>> The identical configuration works with 1.3.
>>
>> Is something requiring TLS v1.3 now that previously worked with 1.2?
>>
> We updated the dependencies for just about everything, including the
> Apache Directory API. The latest version of the Apache LDAP API defaults to
> TLSv1.3:
>
>
> - [DIRAPI-375]https://issues.apache.org/jira/browse/DIRAPI-375) - Add
> TLSv1.3 to default protocols
>
> I suspect this is what you're seeing. You can continue to use the 1.3 LDAP
> extension with Guacamole Client 1.4.0, so that'll work around it for now;
> however, looks like we may need to find a way to make this configurable.
> You're welcome to open a Jira issue for it - I'm sure adding an option for
> TLS version will be reasonably straight-forward.
>
> Thanks, Nick. Happy New Year, by the way!
>
> I opened up an issue and quoted your response there in case someone else
> has the same issue: https://issues.apache.org/jira/browse/GUACAMOLE-1488
>
> I'll try the 1.3 module if I get the server dead enough to try again...
> (had to revert from 1.4 back to 1.3 earlier). if you know of the line to
> change to just hard-code TLS 1.2 for the moment in the 1.4 ldap module, I
> can try that as well.
>
> Jason.
>
>
>
--
S pozdravem
Lukáš Raška
Re: TLSv1.3 requirement in guac 1.4.0?
Posted by Jason Keltz <ja...@yorku.ca>.
On 1/3/2022 11:45 AM, Nick Couchman wrote:
> On Mon, Jan 3, 2022 at 11:18 AM Jason Keltz <ja...@yorku.ca> wrote:
>
> Hi..
>
> I tried to bring install Guac 1.4.0 into place on our CentOS 7
> server running 1.3.0. I kept getting "invalid user" for logins.
> After some debugging, I see in the logs (included below in more
> detail) an exception caused by "Caused by:
> java.lang.IllegalArgumentException: TLSv1.3". I believe there is
> an attempt to connect to the LDAP server with TLS 1.3, and when
> that fails, the auth fails as well, where-as previously TLS 1.2
> would have been used. I may be wrong.
>
> The identical configuration works with 1.3.
>
> Is something requiring TLS v1.3 now that previously worked with 1.2?
>
> We updated the dependencies for just about everything, including the
> Apache Directory API. The latest version of the Apache LDAP API
> defaults to TLSv1.3:
>
> * [DIRAPI-375]https://issues.apache.org/jira/browse/DIRAPI-375) -
> Add TLSv1.3 to default protocols
>
> I suspect this is what you're seeing. You can continue to use the 1.3
> LDAP extension with Guacamole Client 1.4.0, so that'll work around it
> for now; however, looks like we may need to find a way to make this
> configurable. You're welcome to open a Jira issue for it - I'm sure
> adding an option for TLS version will be reasonably straight-forward.
>
Thanks, Nick. Happy New Year, by the way!
I opened up an issue and quoted your response there in case someone else
has the same issue: https://issues.apache.org/jira/browse/GUACAMOLE-1488
I'll try the 1.3 module if I get the server dead enough to try again...
(had to revert from 1.4 back to 1.3 earlier). if you know of the line
to change to just hard-code TLS 1.2 for the moment in the 1.4 ldap
module, I can try that as well.
Jason.
Re: TLSv1.3 requirement in guac 1.4.0?
Posted by Nick Couchman <vn...@apache.org>.
On Mon, Jan 3, 2022 at 11:18 AM Jason Keltz <ja...@yorku.ca> wrote:
> Hi..
>
> I tried to bring install Guac 1.4.0 into place on our CentOS 7 server
> running 1.3.0. I kept getting "invalid user" for logins. After some
> debugging, I see in the logs (included below in more detail) an exception
> caused by "Caused by: java.lang.IllegalArgumentException: TLSv1.3". I
> believe there is an attempt to connect to the LDAP server with TLS 1.3, and
> when that fails, the auth fails as well, where-as previously TLS 1.2 would
> have been used. I may be wrong.
>
> The identical configuration works with 1.3.
>
> Is something requiring TLS v1.3 now that previously worked with 1.2?
>
> We updated the dependencies for just about everything, including the
Apache Directory API. The latest version of the Apache LDAP API defaults to
TLSv1.3:
- [DIRAPI-375]https://issues.apache.org/jira/browse/DIRAPI-375) - Add
TLSv1.3 to default protocols
I suspect this is what you're seeing. You can continue to use the 1.3 LDAP
extension with Guacamole Client 1.4.0, so that'll work around it for now;
however, looks like we may need to find a way to make this configurable.
You're welcome to open a Jira issue for it - I'm sure adding an option for
TLS version will be reasonably straight-forward.
-Nick
>