[ https://issues.jboss.org/browse/ARQ-1370?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč commented on ARQ-1370: --------------------------------- Hey Oliver, I agree that Warp should be able to work with SSL. {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). {quote} The thing is that Warp needs to be able to intercept the request flowing through proxy from client to server - it basically needs to know request/response headers (in order to be able select particular request which should be intercepted). I'm not sure whether LittleProxy current supports SSL handshake - it seems so, however as I said, we are not interested just in transporation level (HTTP-over-SSL), but rather in presentation layer (details of HTTP request). It seems that LittleProxy team recently added support for SSL interception (Man in the Middle - MITM) [1] to 0.6.0-SNAPSHOT (Warp currently uses 0.5.3). {quote} 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. {quote} That's interesting, what have happened in Alpha2: {code} client --HTTPS--> proxy --HTTPS with payload--> server {code} * on the proxy, we had to have access to HTTP headers * in order to add additional request header (which contains payload) How it works in Alpha3: {code} client --HTTPS--> proxy --HTTPS with flag--> server proxy --CommandService--> server {code} * we still need to have access to request headers (adding a flag (serialId of the message) * but proxy needs to be able to connect independently to server You are talking about SSL contexts, but I think it actually stands for SSL certificates setup for {{client}} (browser?) and {{proxy}} (test JVM) and in Alpha3, the {{test}} itself (CommandService, test JVM). Any chance you could look at this issue more closely? I can provide you with guidance. [1] https://github.com/adamfisk/LittleProxy/commit/8cb5b470ad3368badc15d6da67... -- 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