[arquillian-issues] [JBoss JIRA] (ARQ-1370) Warp: support SSL for CommandService using untrusted communication
Lukáš Fryč (JIRA)
jira-events at lists.jboss.org
Mon Apr 8 17:06:42 EDT 2013
[ https://issues.jboss.org/browse/ARQ-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765654#comment-12765654 ]
Lukáš Fryč edited comment on ARQ-1370 at 4/8/13 5:06 PM:
---------------------------------------------------------
Hey Oliver, this might not be ideal solution at all, just the idea which came from my mind (and just to make it clear, I'm not really a guy into security like you are).
Generally:
* {{Alpha2}} didn't need to know anything about the underlying communication (see [[1|https://github.com/lfryc/arquillian.github.com/blob/962cf48dee8ed90f42421ac240704a1379caf3a4/docs/warp.adoc]], [[2|https://github.com/arquillian/arquillian-organization/wiki/Warp-(JSFUnit.NG)]])
** I actually think that any SSL communication wouldn't work in Warp in Alpha2, beucase Warp is a Man in the Middle from the SSL handshake perspective
* {{Alpha3-SNAPSHOT}} no longer communicates just when a client request is triggered but it creates a request also when test is finished in order to collect server's coverage metrics (through the CommandService servlet)
** and here comes a problem - the request for CommandService is redirected and forced to open a SSL request which fails, because the SSL handshake
I guess your client-side tools worked because you used a HTTP client which handled SSL communication. The in-container and Warp test failed, because they weren't able to establish SSL communication. Now the client-side tests fails because CommandService aren't able to establish SSL communication either.
was (Author: lfryc):
Hey Oliver, this might not be ideal solution at all, just the idea which came from my mind (and just to make it clear, I'm not really a guy into security like you are).
Generally:
* {{Alpha2}} didn't need to know anything about the underlying communication (see [[1|https://github.com/lfryc/arquillian.github.com/blob/962cf48dee8ed90f42421ac240704a1379caf3a4/docs/warp.adoc]], [2|https://github.com/arquillian/arquillian-organization/wiki/Warp-(JSFUnit.NG)]])
** I actually think that any SSL communication wouldn't work in Warp in Alpha2, beucase Warp is a Man in the Middle from the SSL handshake perspective
* {{Alpha3-SNAPSHOT}} no longer communicates just when a client request is triggered but it creates a request also when test is finished in order to collect server's coverage metrics (through the CommandService servlet)
** and here comes a problem - the request for CommandService is redirected and forced to open a SSL request which fails, because the SSL handshake
I guess your client-side tools worked because you used a HTTP client which handled SSL communication. The in-container and Warp test failed, because they weren't able to establish SSL communication. Now the client-side tests fails because CommandService aren't able to establish SSL communication either.
> Warp: support SSL for CommandService using untrusted communication
> ------------------------------------------------------------------
>
> Key: ARQ-1370
> URL: https://issues.jboss.org/browse/ARQ-1370
> Project: Arquillian
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Affects Versions: warp_1.0.0.Alpha3
> Reporter: Lukáš Fryč
>
> We can make use of HTTP client which will automatically trust SSL endpoint.
> http://stackoverflow.com/questions/2703161/how-to-ignore-ssl-certificate-errors-in-apache-httpclient-4-0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the arquillian-issues
mailing list