[JBoss JIRA] (ISPN-7556) Decoder2x.readOptionalParams should not call markReaderIndex()
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-7556?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-7556:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/4913
> Decoder2x.readOptionalParams should not call markReaderIndex()
> --------------------------------------------------------------
>
> Key: ISPN-7556
> URL: https://issues.jboss.org/browse/ISPN-7556
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 9.0.0.CR2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.0.0.Final
>
>
> {{Decoder2x.readOptionalParams()}} calls {{buffer.markReaderIndex()}} after reading each parameter, but doesn't save the parameters anywhere. That means if the buffer doesn't contain all the parameters, the decode pass ends unsuccessfully, and the next decode pass doesn't see the parameters read by the previous pass.
> Higher-level methods like {{Decoder2x.readMaybeNamedFactory()}} also call {{readOptionalParams()}} without saving their own state first, meaning their state can be lost as well.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-7556) Decoder2x.readOptionalParams should not call markReaderIndex()
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-7556?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-7556:
-------------------------------
Status: Open (was: New)
> Decoder2x.readOptionalParams should not call markReaderIndex()
> --------------------------------------------------------------
>
> Key: ISPN-7556
> URL: https://issues.jboss.org/browse/ISPN-7556
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 9.0.0.CR2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.0.0.Final
>
>
> {{Decoder2x.readOptionalParams()}} calls {{buffer.markReaderIndex()}} after reading each parameter, but doesn't save the parameters anywhere. That means if the buffer doesn't contain all the parameters, the decode pass ends unsuccessfully, and the next decode pass doesn't see the parameters read by the previous pass.
> Higher-level methods like {{Decoder2x.readMaybeNamedFactory()}} also call {{readOptionalParams()}} without saving their own state first, meaning their state can be lost as well.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-7542) RESTClientWithSniEncryptionIT#testAuthorizedAccessThroughSni fails on all environments
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-7542?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec closed ISPN-7542.
-------------------------------------
Fix Version/s: 9.0.0.Final
Resolution: Won't Fix
> RESTClientWithSniEncryptionIT#testAuthorizedAccessThroughSni fails on all environments
> --------------------------------------------------------------------------------------
>
> Key: ISPN-7542
> URL: https://issues.jboss.org/browse/ISPN-7542
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Reporter: Anna Manukyan
> Assignee: Sebastian Łaskawiec
> Priority: Critical
> Fix For: 9.0.0.Final
>
>
> Test {{RESTClientWithSniEncryptionIT#testAuthorizedAccessThroughSni}} fails on all environments with the following error:
> {code}
> java.lang.AssertionError: expected:<200> but was:<404>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.infinispan.server.test.client.rest.RESTHelper.assertEquals(RESTHelper.java:378)
> at org.infinispan.server.test.client.rest.RESTHelper.put(RESTHelper.java:229)
> at org.infinispan.server.test.client.rest.RESTHelper.put(RESTHelper.java:206)
> at org.infinispan.server.test.client.rest.RESTHelper.put(RESTHelper.java:202)
> at org.infinispan.server.test.client.rest.RESTClientWithSniEncryptionIT.testAuthorizedAccessThroughSni(RESTClientWithSniEncryptionIT.java:85)
> {code}
> The server log is:
> {code}
> &#27;[0m14:24:06,579 INFO [org.jboss.resteasy.plugins.server.netty.i18n] (nioEventLoopGroup-8-1) RESTEASY018512: Exception caught by handler: io.netty.handler.codec.DecoderException: javax.net.ssl.SSLException: Received fatal alert: certificate_unknown
> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:442)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:248)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:350)
> at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926)
> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:129)
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:610)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:551)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:465)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:437)
> at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:873)
> at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.net.ssl.SSLException: Received fatal alert: certificate_unknown
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666)
> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1634)
> at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1800)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:1083)
> at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:907)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)
> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1094)
> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:966)
> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:900)
> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411)
> ... 16 more
> {code}
> The {{RESTClientWithSniEncryptionIT#testUnauthorizedAccessToDefaultSSLContext}} test also fails but randomly with the error:
> {code}
> java.lang.RuntimeException: Could not retrieve HotRod host
> at org.jboss.remoting3.remote.RemoteConnectionChannel.openOutboundMessage(RemoteConnectionChannel.java:115)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.writeMessage(RemoteConnectionChannel.java:307)
> at org.jboss.remotingjmx.protocol.v2.Common.write(Common.java:180)
> at org.jboss.remotingjmx.protocol.v2.ClientConnection$TheConnection.getAttribute(ClientConnection.java:823)
> at org.infinispan.arquillian.utils.MBeanUtils.getMBeanAttribute(MBeanUtils.java:55)
> at org.infinispan.arquillian.core.RESTEndpoint.getInetAddress(RESTEndpoint.java:60)
> at org.infinispan.server.test.client.rest.RESTClientWithSniEncryptionIT.setup(RESTClientWithSniEncryptionIT.java:53)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-7542) RESTClientWithSniEncryptionIT#testAuthorizedAccessThroughSni fails on all environments
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-7542?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec commented on ISPN-7542:
-------------------------------------------
After spending some time analyzing logs, all I can say is that the behavior is correct.
TL;DR
The Rest endpoint tests use [two security realms|https://github.com/infinispan/infinispan/blob/bd241475b14ea70a8a42...]:
{quote}
<security-realm name="SSLRealm1">
<server-identities>
<ssl>
<-- serial number 2a6e347a -->
<keystore path="keystore_client.jks" relative-to="jboss.server.config.dir" keystore-password="secret"/>
</ssl>
</server-identities>
</security-realm>
<security-realm name="SSLRealm2">
<server-identities>
<ssl>
<-- serial number 7311b784 -->
<keystore path="keystore_server.jks" relative-to="jboss.server.config.dir" keystore-password="secret"/>
</ssl>
</server-identities>
</security-realm>
<!-- SSLRealm1 has wrong keystore, so the clients should only be able to connect to SSLRealm2 -->
<!-- There is an additional tests which connects to sni2 and expects cert from SSLRealm1-->
<encryption security-realm="SSLRealm1" require-ssl-client-auth="false" >
<sni host-name="sni" security-realm="SSLRealm2" />
<sni host-name="sni2" />
</encryption>
{quote}
Note that {{SSLRealm1}} is the default one. So if the client don't send any SNI name, the server will serve a certificate {{SSLRealm1}}. This happens after adding {{-Djavax.net.debug=all}} to Arquillian {{javaVmArguments}} parameters:
{quote}
12:59:52,938 INFO [stdout] (MSC service thread 1-1) found key for : hotrod
12:59:52,944 INFO [stdout] (MSC service thread 1-6) chain [0] = [
12:59:52,947 INFO [stdout] (MSC service thread 1-6) [
12:59:52,947 INFO [stdout] (MSC service thread 1-6) Version: V3
12:59:52,947 INFO [stdout] (MSC service thread 1-6) Subject: CN=Martin Gencur, OU=JBoss, O=Red Hat, L=Brno, ST=Czech Republic, C=CS
12:59:52,947 INFO [stdout] (MSC service thread 1-6) Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
12:59:52,948 INFO [stdout] (MSC service thread 1-6)
12:59:52,948 INFO [stdout] (MSC service thread 1-6) Key: Sun RSA public key, 1024 bits
12:59:52,948 INFO [stdout] (MSC service thread 1-6) modulus: 102338023748117186797164348213561979877114961249124128560952833533686446193538602114658758667294909038722152423462436312327412230441215600755949215223502781940747284566575781702964116867372533567195090545516173887913165067381435512908060277226317310077190470965483621194947299282533746397604244036953606499267
12:59:52,948 INFO [stdout] (MSC service thread 1-6) public exponent: 65537
12:59:52,948 INFO [stdout] (MSC service thread 1-6) Validity: [From: Wed Oct 29 13:38:03 CET 2014,
12:59:52,948 INFO [stdout] (MSC service thread 1-6) To: Fri Oct 05 14:38:03 CEST 2114]
12:59:52,948 INFO [stdout] (MSC service thread 1-6) Issuer: CN=Martin Gencur, OU=JBoss, O=Red Hat, L=Brno, ST=Czech Republic, C=CS
12:59:52,949 INFO [stdout] (MSC service thread 1-6) SerialNumber: [ 7311b784]
12:59:52,949 INFO [stdout] (MSC service thread 1-6)
12:59:52,949 INFO [stdout] (MSC service thread 1-6) Certificate Extensions: 1
12:59:52,950 INFO [stdout] (MSC service thread 1-6) [1]: ObjectId: 2.5.29.14 Criticality=false
12:59:52,950 INFO [stdout] (MSC service thread 1-6) SubjectKeyIdentifier [
12:59:52,950 INFO [stdout] (MSC service thread 1-6) KeyIdentifier [
12:59:52,950 INFO [stdout] (MSC service thread 1-6) 0000: B8 0F B3 96 45 44 23 5B 37 44 74 12 A9 DA 07 46 ....ED#[7Dt....F
12:59:52,950 INFO [stdout] (MSC service thread 1-6) 0010: 51 24 E4 4F Q$.O
12:59:52,950 INFO [stdout] (MSC service thread 1-6) ]
12:59:52,951 INFO [stdout] (MSC service thread 1-6) ]
12:59:52,951 INFO [stdout] (MSC service thread 1-6)
12:59:52,951 INFO [stdout] (MSC service thread 1-6) ]
12:59:52,951 INFO [stdout] (MSC service thread 1-6) Algorithm: [SHA256withRSA]
12:59:52,951 INFO [stdout] (MSC service thread 1-6) Signature:
12:59:52,952 INFO [stdout] (MSC service thread 1-6) 0000: 69 0E 2E 12 ED 3D 9C F9 E6 DF 8C 4A CD 91 4E 89 i....=.....J..N.
12:59:52,952 INFO [stdout] (MSC service thread 1-6) 0010: E7 41 CE 3F 37 BA 2B 72 59 6B 68 0C AE B4 E5 68 .A.?7.+rYkh....h
12:59:52,952 INFO [stdout] (MSC service thread 1-6) 0020: 92 10 70 C9 1B 07 CD 93 D8 39 B3 51 A7 04 95 07 ..p......9.Q....
12:59:52,952 INFO [stdout] (MSC service thread 1-6) 0030: 88 E4 35 1E 68 0B 54 5F ED 7C 0F 0C E4 E1 B4 35 ..5.h.T_.......5
12:59:52,952 INFO [stdout] (MSC service thread 1-6) 0040: 30 3B CF A4 22 21 C0 FE B9 78 A1 B3 0C ED 15 54 0;.."!...x.....T
12:59:52,952 INFO [stdout] (MSC service thread 1-6) 0050: B2 E2 AD 57 8D 1A 2A D1 E1 0E 97 B5 20 46 94 D5 ...W..*..... F..
12:59:52,952 INFO [stdout] (MSC service thread 1-6) 0060: AC AD 67 A2 D4 62 7C BC 1F 0A FA 85 FE AF FE D6 ..g..b..........
12:59:52,952 INFO [stdout] (MSC service thread 1-6) 0070: FE 4D 51 BB 67 DC B9 C5 57 E2 79 A0 9E 94 19 5E .MQ.g...W.y....^
12:59:52,953 INFO [stdout] (MSC service thread 1-6)
12:59:52,953 INFO [stdout] (MSC service thread 1-6) ]
12:59:52,953 INFO [stdout] (MSC service thread 1-1) chain [0] = [
12:59:52,953 INFO [stdout] (MSC service thread 1-1) [
12:59:52,953 INFO [stdout] (MSC service thread 1-1) Version: V3
12:59:52,953 INFO [stdout] (MSC service thread 1-1) Subject: CN=HotRod, OU=Infinispan, O=JBoss, L=Red Hat, ST=World, C=WW
12:59:52,953 INFO [stdout] (MSC service thread 1-1) Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
12:59:52,954 INFO [stdout] (MSC service thread 1-1)
12:59:52,954 INFO [stdout] (MSC service thread 1-1) Key: Sun RSA public key, 2048 bits
12:59:52,954 INFO [stdout] (MSC service thread 1-1) modulus: 21018251664460280541114563715302745086345586387923283811089041117168568077159206714254858848912918730236208065171516146343592419386576067888030077455652031741925599334970379048211265992973732477481977380859016715255082471055282522701314460046163047081977111318832082839855291724545854219316749789690188552155372236656642119079158305260423424672151995422243034685382155412220203305821766377062985546649400471863737614201562634587832377736151892140321006804288251975690964648252279553183790676857031726231455083422186950427754499718759806336898052173904040225229393618251054208299558341134916833580887374134770686429959
12:59:52,954 INFO [stdout] (MSC service thread 1-1) public exponent: 65537
12:59:52,954 INFO [stdout] (MSC service thread 1-1) Validity: [From: Fri Mar 29 11:38:05 CET 2013,
12:59:52,954 INFO [stdout] (MSC service thread 1-1) To: Tue Aug 14 12:38:05 CEST 2040]
12:59:52,954 INFO [stdout] (MSC service thread 1-1) Issuer: CN=HotRod, OU=Infinispan, O=JBoss, L=Red Hat, ST=World, C=WW
12:59:52,955 INFO [stdout] (MSC service thread 1-1) SerialNumber: [ 2a6e347a]
12:59:52,955 INFO [stdout] (MSC service thread 1-1)
12:59:52,955 INFO [stdout] (MSC service thread 1-1) Certificate Extensions: 1
12:59:52,955 INFO [stdout] (MSC service thread 1-1) [1]: ObjectId: 2.5.29.14 Criticality=false
12:59:52,955 INFO [stdout] (MSC service thread 1-1) SubjectKeyIdentifier [
12:59:52,955 INFO [stdout] (MSC service thread 1-1) KeyIdentifier [
12:59:52,955 INFO [stdout] (MSC service thread 1-1) 0000: 05 B3 AA 28 7B 8D E0 04 1D 92 5C 54 65 70 10 18 ...(......\Tep..
12:59:52,955 INFO [stdout] (MSC service thread 1-1) 0010: 74 7E 3F D5 t.?.
12:59:52,956 INFO [stdout] (MSC service thread 1-1) ]
12:59:52,956 INFO [stdout] (MSC service thread 1-1) ]
12:59:52,956 INFO [stdout] (MSC service thread 1-1)
12:59:52,956 INFO [stdout] (MSC service thread 1-1) ]
12:59:52,956 INFO [stdout] (MSC service thread 1-1) Algorithm: [SHA256withRSA]
12:59:52,956 INFO [stdout] (MSC service thread 1-1) Signature:
12:59:52,956 INFO [stdout] (MSC service thread 1-1) 0000: 4F 18 76 57 7C F8 BD 48 79 47 D9 32 2C 52 A4 DA O.vW...HyG.2,R..
12:59:52,956 INFO [stdout] (MSC service thread 1-1) 0010: 2A E3 22 4D 0F 47 AB A8 27 13 BF 3E 94 34 FC 4E *."M.G..'..>.4.N
12:59:52,956 INFO [stdout] (MSC service thread 1-1) 0020: 91 1E F4 A2 54 96 9B 64 22 A2 8D 0D A1 F5 5E 27 ....T..d".....^'
12:59:52,957 INFO [stdout] (MSC service thread 1-1) 0030: A5 DC 29 8F 66 08 7A 9B 98 4E 91 36 85 1E 52 9F ..).f.z..N.6..R.
12:59:52,957 INFO [stdout] (MSC service thread 1-1) 0040: 47 7A 69 68 36 71 E9 80 9B F5 7C D7 96 4A 0F A6 Gzih6q.......J..
12:59:52,957 INFO [stdout] (MSC service thread 1-1) 0050: DC 26 19 03 07 F6 34 66 F4 7B 53 20 CA 53 42 2B .&....4f..S .SB+
12:59:52,957 INFO [stdout] (MSC service thread 1-1) 0060: 9B 0F 80 3A 71 35 5F 26 E5 88 64 08 05 97 30 D9 ...:q5_&..d...0.
12:59:52,957 INFO [stdout] (MSC service thread 1-1) 0070: EF 6C D0 A5 FB B7 42 30 22 2C 1D 77 46 BB 55 7A .l....B0",.wF.Uz
12:59:52,957 INFO [stdout] (MSC service thread 1-1) 0080: 5A 21 61 39 32 F7 26 1A F2 7A C3 21 FB CC 90 27 Z!a92.&..z.!...'
12:59:52,957 INFO [stdout] (MSC service thread 1-1) 0090: DD A1 46 60 A7 9E D8 5E DD B4 D4 5C 13 0C E9 8E ..F`...^...\....
12:59:52,958 INFO [stdout] (MSC service thread 1-1) 00A0: 61 A7 97 77 65 2E 00 F0 12 B3 E4 65 5B 66 A7 27 a..we......e[f.'
12:59:52,958 INFO [stdout] (MSC service thread 1-1) 00B0: B6 89 6C 99 1A 49 95 B0 56 6B 62 F5 BC 8D AE 45 ..l..I..Vkb....E
12:59:52,958 INFO [stdout] (MSC service thread 1-1) 00C0: E2 D9 FB A0 37 BB 00 1E 7E 32 0A 51 6B 23 E0 89 ....7....2.Qk#..
12:59:52,958 INFO [stdout] (MSC service thread 1-1) 00D0: C2 19 D4 A2 80 C7 78 64 C6 71 23 50 9F DE E7 52 ......xd.q#P...R
12:59:52,958 INFO [stdout] (MSC service thread 1-1) 00E0: D3 A6 10 70 07 93 BD A5 14 AE EE D0 46 84 FF C9 ...p........F...
12:59:52,959 INFO [stdout] (MSC service thread 1-1) 00F0: EF 0F 38 7D 43 EF 6B E6 2E 85 2C 89 42 46 74 6A ..8.C.k...,.BFtj
12:59:52,959 INFO [stdout] (MSC service thread 1-1)
12:59:52,959 INFO [stdout] (MSC service thread 1-1) ]
12:59:52,959 INFO [stdout] (MSC service thread 1-1) ***
12:59:52,960 INFO [stdout] (MSC service thread 1-6) ***
<-- Server initialized, trying to initiate connection -->
12:59:54,798 INFO [stdout] (nioEventLoopGroup-7-2) *** ClientHello, TLSv1.2
12:59:54,800 INFO [stdout] (nioEventLoopGroup-7-2) Extension server_name, server_name: [type=host_name (0), value=localhost.localdomain]
12:59:54,819 INFO [stdout] (nioEventLoopGroup-7-2) *** ServerHello, TLSv1.2
12:59:54,820 INFO [stdout] (nioEventLoopGroup-7-2) chain [0] = [
12:59:54,820 INFO [stdout] (nioEventLoopGroup-7-2) [
12:59:54,820 INFO [stdout] (nioEventLoopGroup-7-2) Version: V3
12:59:54,820 INFO [stdout] (nioEventLoopGroup-7-2) Subject: CN=HotRod, OU=Infinispan, O=JBoss, L=Red Hat, ST=World, C=WW
12:59:54,820 INFO [stdout] (nioEventLoopGroup-7-2) Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
12:59:54,820 INFO [stdout] (nioEventLoopGroup-7-2)
12:59:54,820 INFO [stdout] (nioEventLoopGroup-7-2) Key: Sun RSA public key, 2048 bits
12:59:54,820 INFO [stdout] (nioEventLoopGroup-7-2) modulus: 21018251664460280541114563715302745086345586387923283811089041117168568077159206714254858848912918730236208065171516146343592419386576067888030077455652031741925599334970379048211265992973732477481977380859016715255082471055282522701314460046163047081977111318832082839855291724545854219316749789690188552155372236656642119079158305260423424672151995422243034685382155412220203305821766377062985546649400471863737614201562634587832377736151892140321006804288251975690964648252279553183790676857031726231455083422186950427754499718759806336898052173904040225229393618251054208299558341134916833580887374134770686429959
12:59:54,820 INFO [stdout] (nioEventLoopGroup-7-2) public exponent: 65537
12:59:54,820 INFO [stdout] (nioEventLoopGroup-7-2) Validity: [From: Fri Mar 29 11:38:05 CET 2013,
12:59:54,820 INFO [stdout] (nioEventLoopGroup-7-2) To: Tue Aug 14 12:38:05 CEST 2040]
12:59:54,820 INFO [stdout] (nioEventLoopGroup-7-2) Issuer: CN=HotRod, OU=Infinispan, O=JBoss, L=Red Hat, ST=World, C=WW
<-- NOTE the serial number, 2a6e347a, it's keystore_client.jks -->
<-- Server sent certificate -->
12:59:54,820 INFO [stdout] (nioEventLoopGroup-7-2) SerialNumber: [ 2a6e347a]
12:59:54,820 INFO [stdout] (nioEventLoopGroup-7-2)
12:59:54,820 INFO [stdout] (nioEventLoopGroup-7-2) Certificate Extensions: 1
12:59:54,820 INFO [stdout] (nioEventLoopGroup-7-2) [1]: ObjectId: 2.5.29.14 Criticality=false
12:59:54,820 INFO [stdout] (nioEventLoopGroup-7-2) SubjectKeyIdentifier [
12:59:54,820 INFO [stdout] (nioEventLoopGroup-7-2) KeyIdentifier [
12:59:54,820 INFO [stdout] (nioEventLoopGroup-7-2) 0000: 05 B3 AA 28 7B 8D E0 04 1D 92 5C 54 65 70 10 18 ...(......\Tep..
12:59:54,820 INFO [stdout] (nioEventLoopGroup-7-2) 0010: 74 7E 3F D5 t.?.
12:59:54,820 INFO [stdout] (nioEventLoopGroup-7-2) ]
12:59:54,820 INFO [stdout] (nioEventLoopGroup-7-2) ]
12:59:54,820 INFO [stdout] (nioEventLoopGroup-7-2)
12:59:54,820 INFO [stdout] (nioEventLoopGroup-7-2) ]
12:59:54,820 INFO [stdout] (nioEventLoopGroup-7-2) Algorithm: [SHA256withRSA]
12:59:54,836 INFO [stdout] (nioEventLoopGroup-7-2) *** CertificateRequest
<-- And then the client fails, because the certificate is not present in the TrustStore -->
12:59:55,679 INFO [stdout] (nioEventLoopGroup-7-2) nioEventLoopGroup-7-2, fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Received fatal alert: certificate_unknown
{quote}
The {{SSLRealm1}} is not present in the TrustStore that is used by the client. This is why we see that the certificate is unknown.
> RESTClientWithSniEncryptionIT#testAuthorizedAccessThroughSni fails on all environments
> --------------------------------------------------------------------------------------
>
> Key: ISPN-7542
> URL: https://issues.jboss.org/browse/ISPN-7542
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Reporter: Anna Manukyan
> Assignee: Sebastian Łaskawiec
> Priority: Critical
>
> Test {{RESTClientWithSniEncryptionIT#testAuthorizedAccessThroughSni}} fails on all environments with the following error:
> {code}
> java.lang.AssertionError: expected:<200> but was:<404>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.infinispan.server.test.client.rest.RESTHelper.assertEquals(RESTHelper.java:378)
> at org.infinispan.server.test.client.rest.RESTHelper.put(RESTHelper.java:229)
> at org.infinispan.server.test.client.rest.RESTHelper.put(RESTHelper.java:206)
> at org.infinispan.server.test.client.rest.RESTHelper.put(RESTHelper.java:202)
> at org.infinispan.server.test.client.rest.RESTClientWithSniEncryptionIT.testAuthorizedAccessThroughSni(RESTClientWithSniEncryptionIT.java:85)
> {code}
> The server log is:
> {code}
> &#27;[0m14:24:06,579 INFO [org.jboss.resteasy.plugins.server.netty.i18n] (nioEventLoopGroup-8-1) RESTEASY018512: Exception caught by handler: io.netty.handler.codec.DecoderException: javax.net.ssl.SSLException: Received fatal alert: certificate_unknown
> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:442)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:248)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:350)
> at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926)
> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:129)
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:610)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:551)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:465)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:437)
> at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:873)
> at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.net.ssl.SSLException: Received fatal alert: certificate_unknown
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666)
> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1634)
> at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1800)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:1083)
> at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:907)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)
> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1094)
> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:966)
> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:900)
> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411)
> ... 16 more
> {code}
> The {{RESTClientWithSniEncryptionIT#testUnauthorizedAccessToDefaultSSLContext}} test also fails but randomly with the error:
> {code}
> java.lang.RuntimeException: Could not retrieve HotRod host
> at org.jboss.remoting3.remote.RemoteConnectionChannel.openOutboundMessage(RemoteConnectionChannel.java:115)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.writeMessage(RemoteConnectionChannel.java:307)
> at org.jboss.remotingjmx.protocol.v2.Common.write(Common.java:180)
> at org.jboss.remotingjmx.protocol.v2.ClientConnection$TheConnection.getAttribute(ClientConnection.java:823)
> at org.infinispan.arquillian.utils.MBeanUtils.getMBeanAttribute(MBeanUtils.java:55)
> at org.infinispan.arquillian.core.RESTEndpoint.getInetAddress(RESTEndpoint.java:60)
> at org.infinispan.server.test.client.rest.RESTClientWithSniEncryptionIT.setup(RESTClientWithSniEncryptionIT.java:53)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-7561) Concurrent async operations access the same LocalTransaction
by Radim Vansa (JIRA)
Radim Vansa created ISPN-7561:
---------------------------------
Summary: Concurrent async operations access the same LocalTransaction
Key: ISPN-7561
URL: https://issues.jboss.org/browse/ISPN-7561
Project: Infinispan
Issue Type: Bug
Components: Core, Transactions
Affects Versions: 9.0.0.CR2
Reporter: Radim Vansa
When two threads in user-started transaction proceed in parallel, these share the {{LocalTransaction}} instance. While the collections in {{LocalTransaction}} are synchronized, some of the instances used (e.g. {{RepeatableReadEntry}}) are not.
The interceptors are not prepared to see different values across the stack, or unsync collections (e.g. entries vs. seen versions) even in one interceptor.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-5357) Hot Rod protocol 3.0
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5357?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5357:
----------------------------------
Description:
Infinispan should expose a single endpoint which should behave as follows:
- by default offer an HTTP/1.1 RESTftul interface
- through HTTP upgrade allow switching to better protocols
- support an HTTP/2 RESTful interface
- support Hot Rod 3.0, which would be a gRPC protocol with additional L2 and L3 intelligence for capable clients
*UPDATE (6/10/2015)*: Hot Rod 3.0 could become a HTTP REST protocol taking advantage of existing infrastructure to deal with HTTP requests efficiently, and if it was based on HTTP 2.0, we could have binary data inside of it. Performance should be on par. Text mode could be available for debug or demos. This essentially would mean REST and Hot Rod would merge into one.
A binary protocol rethink is needed to take better advantage of CPUs and buffering. This is based on the ideas of Martin Thompson's Simple Binary Encoding [blog post|http://mechanical-sympathy.blogspot.cz/2014/05/simple-binary-encoding.html]
In essence, we need to move Hot Rod protocol towards having mostly fixed size fields, hence getting rid of `vInt` and `vLong` formats which although safe some bytes, they hinder long stream reading patterns.
An optional part here would be whether to consider using SBE directly, but this JIRA should be mostly oriented at making sure we have a protocol that can be read fast and efficiently.
was:
*UPDATE (6/10/2015)*: Hot Rod 3.0 could become a HTTP REST protocol taking advantage of existing infrastructure to deal with HTTP requests efficiently, and if it was based on HTTP 2.0, we could have binary data inside of it. Performance should be on par. Text mode could be available for debug or demos. This essentially would mean REST and Hot Rod would merge into one.
A binary protocol rethink is needed to take better advantage of CPUs and buffering. This is based on the ideas of Martin Thompson's Simple Binary Encoding [blog post|http://mechanical-sympathy.blogspot.cz/2014/05/simple-binary-encoding.html]
In essence, we need to move Hot Rod protocol towards having mostly fixed size fields, hence getting rid of `vInt` and `vLong` formats which although safe some bytes, they hinder long stream reading patterns.
An optional part here would be whether to consider using SBE directly, but this JIRA should be mostly oriented at making sure we have a protocol that can be read fast and efficiently.
> Hot Rod protocol 3.0
> --------------------
>
> Key: ISPN-5357
> URL: https://issues.jboss.org/browse/ISPN-5357
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 9.1.0.Final
>
>
> Infinispan should expose a single endpoint which should behave as follows:
> - by default offer an HTTP/1.1 RESTftul interface
> - through HTTP upgrade allow switching to better protocols
> - support an HTTP/2 RESTful interface
> - support Hot Rod 3.0, which would be a gRPC protocol with additional L2 and L3 intelligence for capable clients
> *UPDATE (6/10/2015)*: Hot Rod 3.0 could become a HTTP REST protocol taking advantage of existing infrastructure to deal with HTTP requests efficiently, and if it was based on HTTP 2.0, we could have binary data inside of it. Performance should be on par. Text mode could be available for debug or demos. This essentially would mean REST and Hot Rod would merge into one.
> A binary protocol rethink is needed to take better advantage of CPUs and buffering. This is based on the ideas of Martin Thompson's Simple Binary Encoding [blog post|http://mechanical-sympathy.blogspot.cz/2014/05/simple-binary-encoding.html]
> In essence, we need to move Hot Rod protocol towards having mostly fixed size fields, hence getting rid of `vInt` and `vLong` formats which although safe some bytes, they hinder long stream reading patterns.
> An optional part here would be whether to consider using SBE directly, but this JIRA should be mostly oriented at making sure we have a protocol that can be read fast and efficiently.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month