[
https://issues.apache.org/jira/browse/DIRMINA-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17866965#comment-17866965
]
Nagarjun Reddy Reddymalli commented on DIRMINA-1179:
----------------------------------------------------
Wireshark logs for two communication requests after upgrading mina-core to
2.2.3:
{code:java}
25328 86.164384 127.0.0.1 127.0.0.1 TCP 56 55572 → 8992 [SYN]
Seq=0 Win=65535 Len=0 MSS=65495 WS=256 SACK_PERM
25329 86.164443 127.0.0.1 127.0.0.1 TCP 56 8992 → 55572 [SYN,
ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=65495 WS=256 SACK_PERM
25330 86.164485 127.0.0.1 127.0.0.1 TCP 44 55572 → 8992 [ACK]
Seq=1 Ack=1 Win=2161152 Len=0
25333 86.165965 127.0.0.1 127.0.0.1 TLSv1.2 328 Client Hello
25334 86.166003 127.0.0.1 127.0.0.1 TCP 44 8992 → 55572 [ACK]
Seq=1 Ack=285 Win=2160896 Len=0
25337 86.186250 127.0.0.1 127.0.0.1 TLSv1.2 4636 Server
Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done
25338 86.186305 127.0.0.1 127.0.0.1 TCP 44 55572 → 8992 [ACK]
Seq=285 Ack=4593 Win=2156544 Len=0
25510 86.721657 127.0.0.1 127.0.0.1 TLSv1.2 1984 Certificate
25511 86.721717 127.0.0.1 127.0.0.1 TCP 44 8992 → 55572 [ACK]
Seq=4593 Ack=2225 Win=2159104 Len=0
25512 86.723171 127.0.0.1 127.0.0.1 TLSv1.2 119 Client Key
Exchange
25513 86.723212 127.0.0.1 127.0.0.1 TCP 44 8992 → 55572 [ACK]
Seq=4593 Ack=2300 Win=2158848 Len=0
25514 86.734033 127.0.0.1 127.0.0.1 TLSv1.2 313 Certificate
Verify
25515 86.734081 127.0.0.1 127.0.0.1 TCP 44 8992 → 55572 [ACK]
Seq=4593 Ack=2569 Win=2158592 Len=0
25516 86.734479 127.0.0.1 127.0.0.1 TLSv1.2 50 Change Cipher
Spec
25517 86.734510 127.0.0.1 127.0.0.1 TCP 44 8992 → 55572 [ACK]
Seq=4593 Ack=2575 Win=2158592 Len=0
25518 86.734706 127.0.0.1 127.0.0.1 TLSv1.2 89 Encrypted
Handshake Message
25519 86.734737 127.0.0.1 127.0.0.1 TCP 44 8992 → 55572 [ACK]
Seq=4593 Ack=2620 Win=2158592 Len=0
25522 86.736738 127.0.0.1 127.0.0.1 TLSv1.2 95 Change Cipher
Spec, Encrypted Handshake Message
25523 86.736775 127.0.0.1 127.0.0.1 TCP 44 55572 → 8992 [ACK]
Seq=2620 Ack=4644 Win=2156544 Len=0
25532 86.752760 127.0.0.1 127.0.0.1 TLSv1.2 677 Application
Data
25533 86.752798 127.0.0.1 127.0.0.1 TCP 44 8992 → 55572 [ACK]
Seq=4644 Ack=3253 Win=2158080 Len=0
25536 86.764038 127.0.0.1 127.0.0.1 TLSv1.2 713 Application
Data
25537 86.764095 127.0.0.1 127.0.0.1 TCP 44 55572 → 8992 [ACK]
Seq=3253 Ack=5313 Win=2155776 Len=0
25540 86.764301 127.0.0.1 127.0.0.1 TCP 44 8992 → 55572 [FIN,
ACK] Seq=5313 Ack=3253 Win=2158080 Len=0
25541 86.764327 127.0.0.1 127.0.0.1 TCP 44 55572 → 8992 [ACK]
Seq=3253 Ack=5314 Win=2155776 Len=0
25542 86.771518 127.0.0.1 127.0.0.1 TLSv1.2 75 Encrypted Alert
25543 86.771607 127.0.0.1 127.0.0.1 TCP 44 8992 → 55572 [RST,
ACK] Seq=5314 Ack=3284 Win=0 Len=0
38136 131.924904 127.0.0.1 127.0.0.1 TCP 56 55592 → 8992
[SYN] Seq=0 Win=65535 Len=0 MSS=65495 WS=256 SACK_PERM
38137 131.924980 127.0.0.1 127.0.0.1 TCP 56 8992 → 55592
[SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=65495 WS=256 SACK_PERM
38138 131.925028 127.0.0.1 127.0.0.1 TCP 44 55592 → 8992
[ACK] Seq=1 Ack=1 Win=327424 Len=0
38141 131.926442 127.0.0.1 127.0.0.1 TLSv1.2 360 Client Hello
38142 131.926483 127.0.0.1 127.0.0.1 TCP 44 8992 → 55592
[ACK] Seq=1 Ack=317 Win=2160896 Len=0
38145 131.931143 127.0.0.1 127.0.0.1 TLSv1.2 185 Server
Hello, Change Cipher Spec, Encrypted Handshake Message
38146 131.931191 127.0.0.1 127.0.0.1 TCP 44 55592 → 8992
[ACK] Seq=317 Ack=142 Win=327168 Len=0
38147 131.932252 127.0.0.1 127.0.0.1 TLSv1.2 50 Change Cipher
Spec
38148 131.932285 127.0.0.1 127.0.0.1 TCP 44 8992 → 55592
[ACK] Seq=142 Ack=323 Win=2160896 Len=0
38149 131.932427 127.0.0.1 127.0.0.1 TLSv1.2 89 Encrypted
Handshake Message
38150 131.932452 127.0.0.1 127.0.0.1 TCP 44 8992 → 55592
[ACK] Seq=142 Ack=368 Win=2160896 Len=0
38151 131.933474 127.0.0.1 127.0.0.1 TLSv1.2 677 Application
Data
38152 131.933507 127.0.0.1 127.0.0.1 TCP 44 8992 → 55592
[ACK] Seq=142 Ack=1001 Win=2160128 Len=0
38155 131.944623 127.0.0.1 127.0.0.1 TLSv1.2 713 Application
Data
38156 131.944682 127.0.0.1 127.0.0.1 TCP 44 55592 → 8992
[ACK] Seq=1001 Ack=811 Win=326656 Len=0
38159 131.944922 127.0.0.1 127.0.0.1 TCP 44 8992 → 55592
[FIN, ACK] Seq=811 Ack=1001 Win=2160128 Len=0
38160 131.944959 127.0.0.1 127.0.0.1 TCP 44 55592 → 8992
[ACK] Seq=1001 Ack=812 Win=326656 Len=0
38161 131.947203 127.0.0.1 127.0.0.1 TLSv1.2 75 Encrypted
Alert
38162 131.947365 127.0.0.1 127.0.0.1 TCP 44 8992 → 55592
[RST, ACK] Seq=812 Ack=1032 Win=0 Len=0 {code}
For the First Request: SSL Handshake steps
Server Hello, Certificate, Server Key Exchange,Certificate Request, Server
Hello Done
Certificate
Client Key Exchange
For the requests after the first request:
Server Hello, Change Cipher Spec, Encrypted Handshake Message
We observed that both Server Hello have the same session ID
Reference to how we got session ID is below:
!image-2024-07-18-15-22-41-593.png!
While Using 2.0.25 mina-core jar,
We observed that every request had different session ID.
Each time we see server key Exchange client Key Exchange phases in Handshake.
in case if this is the expected behavior, Is there a way to revert to the old
behavior while using mina-core 2.2.3 ?
> Behavior Change while upgrading mina-core to 2.2.x regarding X509TrustManager
> java class
> -----------------------------------------------------------------------------------------
>
> Key: DIRMINA-1179
> URL: https://issues.apache.org/jira/browse/DIRMINA-1179
> Project: MINA
> Issue Type: Bug
> Components: Core, SSL
> Affects Versions: 2.2.0
> Environment: Operating System: Windows 11
> Jdk 8 : jdk-1.8u411
> Reporter: Nagarjun Reddy Reddymalli
> Priority: Critical
> Attachments: image-2024-07-18-15-22-41-593.png
>
>
> Our project is currently utilizing mina-core 2.0.21.
> We have a client which sends a request to our server as shown below
>
> {code:java}
> SSLContext sslContext = SSLContext.getInstance("TLSv1.2");
> sslContext.init(our keyManager Object, our trustManager Object, null);
> //TrustHostnameVerifier implements HostnameVerifier ( interface from
> java.net.ssl)
> SSLConnectionSocketFactory sslsf = new SSLConnectionSocketFactory(
> sslcontext,
> new String[]{"TLSv1.2"},
> null,
> new TrustHostnameVerifier());
> // We use HTTPClient 4.x to send request to our server where sslCotnext is
> used
> CloseableHttpClient httpclient=
> HttpClients.custom().disableAutomaticRetries().setSSLSocketFactory(
> sslsf).build();
> {code}
> Our Server uses mina-core as server and accepts requests and sends a
> response....
> Every time a response comes back, checkServerTrusted method implementation of
> x509TrustManager class gets called.
> Method :
> [https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/X509TrustManager.html#checkServerTrusted-java.security.cert.X509Certificate:A-java.lang.String-]
>
> After we upgraded mina-core to 2.2.x in our server,
> we observed that the above method (checkServerTrusted) is being called only
> on the first Communication request.
> It is not being called in the later requests until we rebuild the sslContext
> Object. ( or restart the client)
> Observations: Behavior changed from mina-core 2.2.0 where we see that whole
> TLS/SSL implementaion has been revamped
> Question: We see that TLS/SSL has been revamped to fix issues TLSv1.3 . Does
> that mean TLSv1.3 is not supported properly in earlier versions like 2.1.x
> and 2.0.x ?
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
