[JBoss JIRA] (ARQ-1370) Warp: support SSL for CommandService using untrusted communication
by Oliver Bock (JIRA)
[ https://issues.jboss.org/browse/ARQ-1370?page=com.atlassian.jira.plugin.s... ]
Oliver Bock edited comment on ARQ-1370 at 4/9/13 7:25 PM:
----------------------------------------------------------
Great, thanks for the doc pointers! The Arquillian GitHub wiki at [2] would have been the last place for me to look for such Warp details ;-)
{quote}
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
{quote}
Well, as described earlier, it does - at least for client-side tests in a test class annotated with {{@WarpTest}}. That's why this issue seemed like a Alpha2->Alpha3 regression from a user's (my) perspective: for some reason Warp-enriched _client-side_ tests do fail with Alpha3 while they work with Alpha2 (via SSL). You know better than me whether that kind of client-side tests is also affected by the new {{CommandService}} infrastructure/workflow.
I guess the major difference compared to Alpha2 is the _additional_ request in Alpha3 you describe: while Alpha2 (enriched) client-side tests, issuing requests via Drone/WebDriver, simply run in JBoss's configured SSL context, Alpha3 (enriched) client-side tests involve {{CommandService}} creating a new request _itself_, somehow outside the container's SSL context...? If my assessment is correct the question should be, can you tap into the container's SSL context or adopt it somehow? If not, you most likely need to establish your own, as suggested by your proposed workaround, if Warp's architecture itself can't be changed/improved in that regard.
IMHO, such a workaround would be less optimal, however, because a functional JSF test naturally involves the web app's container, including potential security measures in place (like SSL or authentication). Thus it would be nice to run such tests in their actual environment, without the need for a parallel security setup that (potentially) needs to be kept in sync with the container's setup in order to produce meaningful test results (without superfluous artefacts). After all, this is what makes Arquillian such a great tool, right?
What do you reckon? Seems like an interesting problem :-)
was (Author: brevilo):
Great, thanks for the doc pointers! The Arquillian GitHub wiki at [2] would have been the last place for me to look for such Warp details ;-)
{quote}
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
{quote}
Well, as described earlier, it does - at least for client-side tests in a test class annotated with {{@WarpTest}}. That's why this issue seemed like a Alpha2->Alpha3 regression from a user's (my) perspective: for some reason Warp-enriched _client-side_ tests do fail with Alpha3 while they work with Alpha2 (via SSL). You know better than me whether that kind of client-side tests is also affected by the new {{CommandService}} infrastructure/workflow.
I guess the major difference compared to Alpha2 is the _additional_ request in Alpha3 you describe: while Alpha2 (enriched) client-side tests, issuing requests via Drone/WebDriver, simply run in JBoss's configured SSL context, Alpha3 (enriched) client-side tests involve {{CommandService}} creating a new request _itself_, somehow outside the container's SSL context...? If my assessment is correct the question should be, can you tap into the container's SSL context or adopt it somehow? If not, you most likely need to establish your own, as suggested by your proposed workaround, if Warp's architecture itself can't be changed/improved in that regard.
IMHO, such a workaround would be less optimal, however, because a functional JSF test naturally involves the web app's container, including potential security measures in place (like SSL or authentication). Thus it would be nice to run such tests in their actual environment, without the need for a parallel security setup that (potentially) needs to be kept in sync with the container's setup in order to produce meaningful test results (without superfluous artefacts). This is what Arquillian is all about after all, right?
What do you reckon? Seems like an interesting problem :-)
> 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-...
--
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
11 years, 9 months
[JBoss JIRA] (ARQ-1370) Warp: support SSL for CommandService using untrusted communication
by Oliver Bock (JIRA)
[ https://issues.jboss.org/browse/ARQ-1370?page=com.atlassian.jira.plugin.s... ]
Oliver Bock edited comment on ARQ-1370 at 4/9/13 6:50 PM:
----------------------------------------------------------
Great, thanks for the doc pointers! The Arquillian GitHub wiki at [2] would have been the last place for me to look for such Warp details ;-)
{quote}
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
{quote}
Well, as described earlier, it does - at least for client-side tests in a test class annotated with {{@WarpTest}}. That's why this issue seemed like a Alpha2->Alpha3 regression from a user's (my) perspective: for some reason Warp-enriched _client-side_ tests do fail with Alpha3 while they work with Alpha2 (via SSL). You know better than me whether that kind of client-side tests is also affected by the new {{CommandService}} infrastructure/workflow.
I guess the major difference compared to Alpha2 is the _additional_ request in Alpha3 you describe: while Alpha2 (enriched) client-side tests, issuing requests via Drone/WebDriver, simply run in JBoss's configured SSL context, Alpha3 (enriched) client-side tests involve {{CommandService}} creating a new request _itself_, somehow outside the container's SSL context...? If my assessment is correct the question should be, can you tap into the container's SSL context or adopt it somehow? If not, you most likely need to establish your own, as suggested by your proposed workaround, if Warp's architecture itself can't be changed/improved in that regard.
IMHO, such a workaround would be less optimal, however, because a functional JSF test naturally involves the web app's container, including potential security measures in place (like SSL or authentication). Thus it would be nice to run such tests in their actual environment, without the need for a parallel security setup that (potentially) needs to be kept in sync with the container's setup in order to produce meaningful test results (without superfluous artefacts). This is what Arquillian is all about after all, right? :-)
Thoughts?
was (Author: brevilo):
Great, thanks for the doc pointers! The Arquillian GitHub wiki at [2] would have been the last place for me to look for such Warp details ;-)
{quote}
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
{quote}
Well, as described earlier, it does - at least for client-side tests in a test class annotated with {{@WarpTest}}. That's why this issue seemed like a Alpha2->Alpha3 regression from a user's (my) perspective: for some reason Warp-enriched _client-side_ tests do fail with Alpha3 while they work with Alpha2 (via SSL). You know better than me whether that kind of client-side tests is also affected by the new {{CommandService}} infrastructure/workflow.
I guess the major difference compared to Alpha2 is the _additional_ request in Alpha3 you describe: while Alpha2 (enriched) client-side tests, issuing requests via Drone/WebDriver, simply run in JBoss's configured SSL context, Alpha3 (enriched) client-side tests involve {{CommandService}} creating a new request _itself_, somehow outside the container's SSL context...? If my assessment is correct the question should be, can you tap into the container's SSL context or adopt it somehow? If not, you most likely need to establish your own, as suggested by your proposed workaround, if the architecture itself can't be changed/improved.
IMHO, such a workaround would be less optimal, however, because a functional JSF test naturally involves the web app's container, including potential security measures in place (like SSL or authentication). Thus it would be nice to run such tests in their actual environment, without the need for a parallel security setup that (potentially) needs to be kept in sync with the container's setup in order to produce meaningful test results (without superfluous artefacts). This is what Arquillian is all about after all, right? :-)
Thoughts?
> 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-...
--
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
11 years, 9 months
[JBoss JIRA] (ARQ-1370) Warp: support SSL for CommandService using untrusted communication
by Oliver Bock (JIRA)
[ https://issues.jboss.org/browse/ARQ-1370?page=com.atlassian.jira.plugin.s... ]
Oliver Bock commented on ARQ-1370:
----------------------------------
Great, thanks for the doc pointers! The Arquillian GitHub wiki at [2] would have been the last place for me to look for such Warp details ;-)
{quote}
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
{quote}
Well, as described earlier, it does - at least for client-side tests in a test class annotated with {{@WarpTest}}. That's why this issue seemed like a Alpha2->Alpha3 regression from a user's (my) perspective: for some reason Warp-enriched _client-side_ tests do fail with Alpha3 while they work with Alpha2 (via SSL). You know better than me whether that kind of client-side tests is also affected by the new {{CommandService}} infrastructure/workflow.
I guess the major difference compared to Alpha2 is the _additional_ request in Alpha3 you describe: while Alpha2 (enriched) client-side tests, issuing requests via Drone/WebDriver, would simply run in JBoss's configured SSL context, Alpha3 (enriched) client-side tests involve {{CommandService}} creating a new request _itself_, somehow outside the container's SSL context...? If my assessment is correct the question should be, can you tap into the container's SSL context or adopt it somehow? If not, you most likely need to establish your own, as suggested by your proposed workaround, if the architecture itself can't be changed/improved.
IMHO, this would be less optimal, however, because a functional JSF test naturally involves the web app's container, including potential security measures in place (like SSL or authentication). Thus it would be nice to run such tests in their actual environment, without the need for a parallel security setup the potentially needs to be kept in sync with the container's setup in order to produce meaningful test results (without superfluous artefacts).
Thoughts?
> 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-...
--
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
11 years, 9 months
[JBoss JIRA] (ARQ-1370) Warp: support SSL for CommandService using untrusted communication
by Oliver Bock (JIRA)
[ https://issues.jboss.org/browse/ARQ-1370?page=com.atlassian.jira.plugin.s... ]
Oliver Bock edited comment on ARQ-1370 at 4/9/13 6:47 PM:
----------------------------------------------------------
Great, thanks for the doc pointers! The Arquillian GitHub wiki at [2] would have been the last place for me to look for such Warp details ;-)
{quote}
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
{quote}
Well, as described earlier, it does - at least for client-side tests in a test class annotated with {{@WarpTest}}. That's why this issue seemed like a Alpha2->Alpha3 regression from a user's (my) perspective: for some reason Warp-enriched _client-side_ tests do fail with Alpha3 while they work with Alpha2 (via SSL). You know better than me whether that kind of client-side tests is also affected by the new {{CommandService}} infrastructure/workflow.
I guess the major difference compared to Alpha2 is the _additional_ request in Alpha3 you describe: while Alpha2 (enriched) client-side tests, issuing requests via Drone/WebDriver, would simply run in JBoss's configured SSL context, Alpha3 (enriched) client-side tests involve {{CommandService}} creating a new request _itself_, somehow outside the container's SSL context...? If my assessment is correct the question should be, can you tap into the container's SSL context or adopt it somehow? If not, you most likely need to establish your own, as suggested by your proposed workaround, if the architecture itself can't be changed/improved.
IMHO, such a workaround would be less optimal, however, because a functional JSF test naturally involves the web app's container, including potential security measures in place (like SSL or authentication). Thus it would be nice to run such tests in their actual environment, without the need for a parallel security setup that (potentially) needs to be kept in sync with the container's setup in order to produce meaningful test results (without superfluous artefacts). This is what Arquillian is all about after all, right? :-)
Thoughts?
was (Author: brevilo):
Great, thanks for the doc pointers! The Arquillian GitHub wiki at [2] would have been the last place for me to look for such Warp details ;-)
{quote}
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
{quote}
Well, as described earlier, it does - at least for client-side tests in a test class annotated with {{@WarpTest}}. That's why this issue seemed like a Alpha2->Alpha3 regression from a user's (my) perspective: for some reason Warp-enriched _client-side_ tests do fail with Alpha3 while they work with Alpha2 (via SSL). You know better than me whether that kind of client-side tests is also affected by the new {{CommandService}} infrastructure/workflow.
I guess the major difference compared to Alpha2 is the _additional_ request in Alpha3 you describe: while Alpha2 (enriched) client-side tests, issuing requests via Drone/WebDriver, would simply run in JBoss's configured SSL context, Alpha3 (enriched) client-side tests involve {{CommandService}} creating a new request _itself_, somehow outside the container's SSL context...? If my assessment is correct the question should be, can you tap into the container's SSL context or adopt it somehow? If not, you most likely need to establish your own, as suggested by your proposed workaround, if the architecture itself can't be changed/improved.
IMHO, this would be less optimal, however, because a functional JSF test naturally involves the web app's container, including potential security measures in place (like SSL or authentication). Thus it would be nice to run such tests in their actual environment, without the need for a parallel security setup the potentially needs to be kept in sync with the container's setup in order to produce meaningful test results (without superfluous artefacts).
Thoughts?
> 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-...
--
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
11 years, 9 months
[JBoss JIRA] (ARQ-1370) Warp: support SSL for CommandService using untrusted communication
by Oliver Bock (JIRA)
[ https://issues.jboss.org/browse/ARQ-1370?page=com.atlassian.jira.plugin.s... ]
Oliver Bock edited comment on ARQ-1370 at 4/9/13 6:49 PM:
----------------------------------------------------------
Great, thanks for the doc pointers! The Arquillian GitHub wiki at [2] would have been the last place for me to look for such Warp details ;-)
{quote}
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
{quote}
Well, as described earlier, it does - at least for client-side tests in a test class annotated with {{@WarpTest}}. That's why this issue seemed like a Alpha2->Alpha3 regression from a user's (my) perspective: for some reason Warp-enriched _client-side_ tests do fail with Alpha3 while they work with Alpha2 (via SSL). You know better than me whether that kind of client-side tests is also affected by the new {{CommandService}} infrastructure/workflow.
I guess the major difference compared to Alpha2 is the _additional_ request in Alpha3 you describe: while Alpha2 (enriched) client-side tests, issuing requests via Drone/WebDriver, simply run in JBoss's configured SSL context, Alpha3 (enriched) client-side tests involve {{CommandService}} creating a new request _itself_, somehow outside the container's SSL context...? If my assessment is correct the question should be, can you tap into the container's SSL context or adopt it somehow? If not, you most likely need to establish your own, as suggested by your proposed workaround, if the architecture itself can't be changed/improved.
IMHO, such a workaround would be less optimal, however, because a functional JSF test naturally involves the web app's container, including potential security measures in place (like SSL or authentication). Thus it would be nice to run such tests in their actual environment, without the need for a parallel security setup that (potentially) needs to be kept in sync with the container's setup in order to produce meaningful test results (without superfluous artefacts). This is what Arquillian is all about after all, right? :-)
Thoughts?
was (Author: brevilo):
Great, thanks for the doc pointers! The Arquillian GitHub wiki at [2] would have been the last place for me to look for such Warp details ;-)
{quote}
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
{quote}
Well, as described earlier, it does - at least for client-side tests in a test class annotated with {{@WarpTest}}. That's why this issue seemed like a Alpha2->Alpha3 regression from a user's (my) perspective: for some reason Warp-enriched _client-side_ tests do fail with Alpha3 while they work with Alpha2 (via SSL). You know better than me whether that kind of client-side tests is also affected by the new {{CommandService}} infrastructure/workflow.
I guess the major difference compared to Alpha2 is the _additional_ request in Alpha3 you describe: while Alpha2 (enriched) client-side tests, issuing requests via Drone/WebDriver, would simply run in JBoss's configured SSL context, Alpha3 (enriched) client-side tests involve {{CommandService}} creating a new request _itself_, somehow outside the container's SSL context...? If my assessment is correct the question should be, can you tap into the container's SSL context or adopt it somehow? If not, you most likely need to establish your own, as suggested by your proposed workaround, if the architecture itself can't be changed/improved.
IMHO, such a workaround would be less optimal, however, because a functional JSF test naturally involves the web app's container, including potential security measures in place (like SSL or authentication). Thus it would be nice to run such tests in their actual environment, without the need for a parallel security setup that (potentially) needs to be kept in sync with the container's setup in order to produce meaningful test results (without superfluous artefacts). This is what Arquillian is all about after all, right? :-)
Thoughts?
> 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-...
--
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
11 years, 9 months
[JBoss JIRA] (ARQ-1370) Warp: support SSL for CommandService using untrusted communication
by Oliver Bock (JIRA)
[ https://issues.jboss.org/browse/ARQ-1370?page=com.atlassian.jira.plugin.s... ]
Oliver Bock edited comment on ARQ-1370 at 4/9/13 6:52 PM:
----------------------------------------------------------
Great, thanks for the doc pointers! The Arquillian GitHub wiki at [2] would have been the last place for me to look for such Warp details ;-)
{quote}
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
{quote}
Well, as described earlier, it does - at least for client-side tests in a test class annotated with {{@WarpTest}}. That's why this issue seemed like a Alpha2->Alpha3 regression from a user's (my) perspective: for some reason Warp-enriched _client-side_ tests do fail with Alpha3 while they work with Alpha2 (via SSL). You know better than me whether that kind of client-side tests is also affected by the new {{CommandService}} infrastructure/workflow.
I guess the major difference compared to Alpha2 is the _additional_ request in Alpha3 you describe: while Alpha2 (enriched) client-side tests, issuing requests via Drone/WebDriver, simply run in JBoss's configured SSL context, Alpha3 (enriched) client-side tests involve {{CommandService}} creating a new request _itself_, somehow outside the container's SSL context...? If my assessment is correct the question should be, can you tap into the container's SSL context or adopt it somehow? If not, you most likely need to establish your own, as suggested by your proposed workaround, if Warp's architecture itself can't be changed/improved in that regard.
IMHO, such a workaround would be less optimal, however, because a functional JSF test naturally involves the web app's container, including potential security measures in place (like SSL or authentication). Thus it would be nice to run such tests in their actual environment, without the need for a parallel security setup that (potentially) needs to be kept in sync with the container's setup in order to produce meaningful test results (without superfluous artefacts). This is what Arquillian is all about after all, right? :-)
What do you think?
was (Author: brevilo):
Great, thanks for the doc pointers! The Arquillian GitHub wiki at [2] would have been the last place for me to look for such Warp details ;-)
{quote}
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
{quote}
Well, as described earlier, it does - at least for client-side tests in a test class annotated with {{@WarpTest}}. That's why this issue seemed like a Alpha2->Alpha3 regression from a user's (my) perspective: for some reason Warp-enriched _client-side_ tests do fail with Alpha3 while they work with Alpha2 (via SSL). You know better than me whether that kind of client-side tests is also affected by the new {{CommandService}} infrastructure/workflow.
I guess the major difference compared to Alpha2 is the _additional_ request in Alpha3 you describe: while Alpha2 (enriched) client-side tests, issuing requests via Drone/WebDriver, simply run in JBoss's configured SSL context, Alpha3 (enriched) client-side tests involve {{CommandService}} creating a new request _itself_, somehow outside the container's SSL context...? If my assessment is correct the question should be, can you tap into the container's SSL context or adopt it somehow? If not, you most likely need to establish your own, as suggested by your proposed workaround, if Warp's architecture itself can't be changed/improved in that regard.
IMHO, such a workaround would be less optimal, however, because a functional JSF test naturally involves the web app's container, including potential security measures in place (like SSL or authentication). Thus it would be nice to run such tests in their actual environment, without the need for a parallel security setup that (potentially) needs to be kept in sync with the container's setup in order to produce meaningful test results (without superfluous artefacts). This is what Arquillian is all about after all, right? :-)
Thoughts?
> 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-...
--
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
11 years, 9 months