[jira] [Commented] (NET-579) SSL/TLS SocketClients do not verify the hostname against the certificate
[
https://issues.apache.org/jira/browse/NET-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14708551#comment-14708551
]
Sebb commented on NET-579:
--
Have you a patch that would meet the requirements?
> SSL/TLS SocketClients do not verify the hostname against the certificate
>
>
> Key: NET-579
> URL: https://issues.apache.org/jira/browse/NET-579
> Project: Commons Net
> Issue Type: Bug
> Components: FTP, IMAP, POP3, SMTP
>Affects Versions: 3.3
> Environment: Java 1.7 (earlier versions cannot verify the hostname)
>Reporter: Simon Arlott
>Priority: Critical
> Labels: security
> Attachments: NET-579.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Every subclass of SocketClient that does SSL/TLS will never verify the
> hostname of the server against the certificate. This means that any valid
> certificate for any CA in the default trust store will be accepted without
> error.
> SocketClient should be modified to store the hostname, and
> SMTPSClient/FTPSClient/IMAPSClient/POP3SClient should use it when negotiating
> SSL/TLS.
> Java 1.7 has support for verifying the hostname if
> SSLParameters.setEndpointIdentificationAlgorithm("HTTPS") is used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NET-579) SSL/TLS SocketClients do not verify the hostname against the certificate
[
https://issues.apache.org/jira/browse/NET-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14708548#comment-14708548
]
Simon Arlott commented on NET-579:
--
The hostname has to be retained (there's no API change required for that).
For Java 1.7+, there needs to be a way to call
setEndpointIdentificationAlgorithm("HTTPS") on the SSLParameters for the
SSLSocket, before negotiating TLS.
For everything else (i.e. Android), there needs to a post-TLS verification
check using the SSLSession (which can be obtained from the SSLSocket) and the
hostname. This could either be a protected method that has to be overridden or
a callback interface that takes a hostname and SSLSocket/SSLSession and returns
a boolean verification result.
> SSL/TLS SocketClients do not verify the hostname against the certificate
>
>
> Key: NET-579
> URL: https://issues.apache.org/jira/browse/NET-579
> Project: Commons Net
> Issue Type: Bug
> Components: FTP, IMAP, POP3, SMTP
>Affects Versions: 3.3
> Environment: Java 1.7 (earlier versions cannot verify the hostname)
>Reporter: Simon Arlott
>Priority: Critical
> Labels: security
> Attachments: NET-579.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Every subclass of SocketClient that does SSL/TLS will never verify the
> hostname of the server against the certificate. This means that any valid
> certificate for any CA in the default trust store will be accepted without
> error.
> SocketClient should be modified to store the hostname, and
> SMTPSClient/FTPSClient/IMAPSClient/POP3SClient should use it when negotiating
> SSL/TLS.
> Java 1.7 has support for verifying the hostname if
> SSLParameters.setEndpointIdentificationAlgorithm("HTTPS") is used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NET-579) SSL/TLS SocketClients do not verify the hostname against the certificate
[
https://issues.apache.org/jira/browse/NET-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14708543#comment-14708543
]
Sebb commented on NET-579:
--
bq. "The connection is supposed to fail when it's not secure"
Is that documented anywhere in NET?
I agree with [~bogdro] that it does not seem sensible to change NET as
suggested.
However if there are some additions to the API needed in order to support
custom code please provide details.
> SSL/TLS SocketClients do not verify the hostname against the certificate
>
>
> Key: NET-579
> URL: https://issues.apache.org/jira/browse/NET-579
> Project: Commons Net
> Issue Type: Bug
> Components: FTP, IMAP, POP3, SMTP
>Affects Versions: 3.3
> Environment: Java 1.7 (earlier versions cannot verify the hostname)
>Reporter: Simon Arlott
>Priority: Critical
> Labels: security
> Attachments: NET-579.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Every subclass of SocketClient that does SSL/TLS will never verify the
> hostname of the server against the certificate. This means that any valid
> certificate for any CA in the default trust store will be accepted without
> error.
> SocketClient should be modified to store the hostname, and
> SMTPSClient/FTPSClient/IMAPSClient/POP3SClient should use it when negotiating
> SSL/TLS.
> Java 1.7 has support for verifying the hostname if
> SSLParameters.setEndpointIdentificationAlgorithm("HTTPS") is used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NET-579) SSL/TLS SocketClients do not verify the hostname against the certificate
[
https://issues.apache.org/jira/browse/NET-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14708090#comment-14708090
]
Simon Arlott commented on NET-579:
--
The connection is supposed to fail when it's not secure, and there is no
TrustManager that checks the hostname. There's also no API in commons-net to
replace the SSLSocketFactory that is used. Even with a custom
TrustManager/SSLSocketFactory you still don't have access to the hostname
because the code in commons-net discards it.
> SSL/TLS SocketClients do not verify the hostname against the certificate
>
>
> Key: NET-579
> URL: https://issues.apache.org/jira/browse/NET-579
> Project: Commons Net
> Issue Type: Bug
> Components: FTP, IMAP, POP3, SMTP
>Affects Versions: 3.3
> Environment: Java 1.7 (earlier versions cannot verify the hostname)
>Reporter: Simon Arlott
>Priority: Critical
> Labels: security
> Attachments: NET-579.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Every subclass of SocketClient that does SSL/TLS will never verify the
> hostname of the server against the certificate. This means that any valid
> certificate for any CA in the default trust store will be accepted without
> error.
> SocketClient should be modified to store the hostname, and
> SMTPSClient/FTPSClient/IMAPSClient/POP3SClient should use it when negotiating
> SSL/TLS.
> Java 1.7 has support for verifying the hostname if
> SSLParameters.setEndpointIdentificationAlgorithm("HTTPS") is used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NET-579) SSL/TLS SocketClients do not verify the hostname against the certificate
[
https://issues.apache.org/jira/browse/NET-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14708046#comment-14708046
]
Bogdan Drozdowski commented on NET-579:
---
The patch looks nice, but you can already achieve this functionality - you can
always set your own TrustManager in the client instance, e.g.
FTPSClient.setTrustManager(), or use a custom SocketFactory.
This wouldn't require Java 7 by Commons-NET, would allow to set even more
parameters than these and enable any certificate validations you would wish.
Sure, it's less convenient, because you have to code more on the client side.
I'm not a Commons-NET developer, but I don't think I'd like such a change in
the code. The problem is that a certificate can be issued to a host name and
thus connecting using an IP address would fail or vice versa (a test
certificate issued for an IP address inside some local network, and clients
connecting with hostnames by a local DNS).
> SSL/TLS SocketClients do not verify the hostname against the certificate
>
>
> Key: NET-579
> URL: https://issues.apache.org/jira/browse/NET-579
> Project: Commons Net
> Issue Type: Bug
> Components: FTP, IMAP, POP3, SMTP
>Affects Versions: 3.3
> Environment: Java 1.7 (earlier versions cannot verify the hostname)
>Reporter: Simon Arlott
>Priority: Critical
> Labels: security
> Attachments: NET-579.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Every subclass of SocketClient that does SSL/TLS will never verify the
> hostname of the server against the certificate. This means that any valid
> certificate for any CA in the default trust store will be accepted without
> error.
> SocketClient should be modified to store the hostname, and
> SMTPSClient/FTPSClient/IMAPSClient/POP3SClient should use it when negotiating
> SSL/TLS.
> Java 1.7 has support for verifying the hostname if
> SSLParameters.setEndpointIdentificationAlgorithm("HTTPS") is used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NET-579) SSL/TLS SocketClients do not verify the hostname against the certificate
[
https://issues.apache.org/jira/browse/NET-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707954#comment-14707954
]
Simon Arlott commented on NET-579:
--
Note, on Android there is no
SSLParameters.setEndpointIdentificationAlgorithm("HTTPS") and the only viable
option appears to be to extend the client (to gain access to _socket_) and use
the deprecated StrictHostnameVerifier to perform the check.
> SSL/TLS SocketClients do not verify the hostname against the certificate
>
>
> Key: NET-579
> URL: https://issues.apache.org/jira/browse/NET-579
> Project: Commons Net
> Issue Type: Bug
> Components: FTP, IMAP, POP3, SMTP
>Affects Versions: 3.3
> Environment: Java 1.7 (earlier versions cannot verify the hostname)
>Reporter: Simon Arlott
>Priority: Critical
> Labels: security
> Attachments: NET-579.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Every subclass of SocketClient that does SSL/TLS will never verify the
> hostname of the server against the certificate. This means that any valid
> certificate for any CA in the default trust store will be accepted without
> error.
> SocketClient should be modified to store the hostname, and
> SMTPSClient/FTPSClient/IMAPSClient/POP3SClient should use it when negotiating
> SSL/TLS.
> Java 1.7 has support for verifying the hostname if
> SSLParameters.setEndpointIdentificationAlgorithm("HTTPS") is used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
