client authentication with revoked cert results in server no response.

[huican ping]

My client got the same behavior as before by replacing with the new
lib from rev1174.
I am building the whole project from scratch to have another try, but
the above is what I got by replacing the lib.

On Fri, Apr 10, 2009 at 1:18 PM, Trustin Lee <tlee at redhat.com> wrote:
> I have made a small change to my fix so that unwrap can be called at
> least once.  Rev # is 1174.
>
> I want to fix this problem asap, so please help me by responding asap. :-)
>
> — Trustin Lee, http://gleamynode.net/
>
>
>
> On Sat, Apr 11, 2009 at 2:37 AM, huican ping <pinghuican at gmail.com> wrote:
>> Hello Trustin,
>>
>> Also currently i have problem to generate a test code because lack of time.
>>
>> Try 1171.
>> Now CPU is low, but:
>> The message doesn't go down to to our http handler, e.g,
>> exceptionCaught() there not get called, probably no exception was
>> throw?. (initially, for first 4 client requests, I got ssh error
>> back).
>> Now nothing was replied to client, and the client is just stuck
>> waiting for reply back from server for ever.
>>
>>
>> Our pipeline:
>> =============
>> pipeline.addLast("SslEngine", new SslHandler(engine));
>> pipeline.addLast("decoder", new HttpRequestDecoder());
>> pipeline.addLast("encoder", new HttpResponseEncoder());
>> pipeline.addLast("handler", httpHandler);
>>
>>
>> For part of ssl dump:
>> =====================
>> ***
>> New I/O server worker #1-3, fatal error: 46: General SSLEngine problem
>> sun.security.validator.ValidatorException: PKIX path building failed:
>> sun.security.provider.certpath.SunCertP
>> xception: unable to find valid certification path to requested target
>> New I/O server worker #1-3, SEND TLSv1 ALERT:  fatal, description =
>> certificate_unknown
>> New I/O server worker #1-3, WRITE: TLSv1 Alert, length = 2
>>
>>
>> I noticed the ssl handler breaks the unwrap method at this place at
>> its last time:
>>    boolean inboundDone = engine.isInboundDone();
>>    if (inboundDone) {
>>        break;
>>    }
>>
>>
>> On Fri, Apr 10, 2009 at 12:53 AM, Trustin Lee <tlee at redhat.com> wrote:
>>> I removed a sanity check code which might be causing this problem.  Rev 1169.
>>>
>>> — Trustin Lee, http://gleamynode.net/
>>>
>>>
>>>
>>> On Fri, Apr 10, 2009 at 2:47 PM, Trustin Lee <tlee at redhat.com> wrote:
>>>> How's the CPU consumption?  Is it normal now?
>>>>
>>>> It would be nice if you could provide me reproduceable code off the list.
>>>>
>>>> — Trustin Lee, http://gleamynode.net/
>>>>
>>>> On Fri, Apr 10, 2009 at 2:16 PM, huican ping <pinghuican at gmail.com> wrote:
>>>>> Hello Trustin,
>>>>>
>>>>> It seems not good.
>>>>>
>>>>> Now for the bad ssl handshake case, the client just stuck in waiting
>>>>> for the reply from server, but the server doesn't return anything
>>>>> after the handshake failed.
>>>>>
>>>>> For the normal case, it is still working.
>>>>>
>>>>> Not sure whether it is my setup problem here (but I don't think so).
>>>>>
>>>>> Huican
>>>>>
>>>>> On Thu, Apr 9, 2009 at 7:58 PM, Trustin Lee <tlee at redhat.com> wrote:
>>>>>> Hi Huican,
>>>>>>
>>>>>> Thanks for the detailed analysis.  I checked in the potential fix for
>>>>>> this issue.  Could you let me know if my fix works for you?  Revision
>>>>>> # is 1163.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> — Trustin Lee, http://gleamynode.net/
>>>>>>
>>>>>> On Fri, Apr 10, 2009 at 9:00 AM, huican ping <pinghuican at gmail.com> wrote:
>>>>>>> Hello Trustin,
>>>>>>>
>>>>>>> Just steped through the code, and netty code FINALLY stuck in a loop
>>>>>>> in unwrap() with condition inNetBuf.hasRemaining()=true.
>>>>>>>
>>>>>>> private ChannelBuffer unwrap(
>>>>>>> // inside there is an infinite loop
>>>>>>> ...
>>>>>>>    case NEED_UNWRAP:
>>>>>>>        if (inNetBuf.hasRemaining()) {
>>>>>>>            break;
>>>>>>>        } else {
>>>>>>>            break loop;
>>>>>>>        }
>>>>>>> ....
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> More carefully, When the bad message comes in initially, it goes
>>>>>>> messageReceived(), some time later sshHandler.decode() goes into this
>>>>>>> unwrap() method. This time it goes out this inifite loop without
>>>>>>> problem.
>>>>>>>
>>>>>>> Because of handshake problem, after throwing SSLHandlshakeException, I
>>>>>>> close channel at exceptionCaught() in my httpHandler code. Some time
>>>>>>> later the netty code goes into closeOutboundAndChannel() method in
>>>>>>> SslHandler, it calls unwrap() method also. it did break out the
>>>>>>> infinite loop first time. Then evaluate engine.isInboundDone() is
>>>>>>> true, and it goes contenxt.sendDownstream(e).
>>>>>>>
>>>>>>> With this sendDownStream(e) call, the code goes into this unwrap()
>>>>>>> call again, and forever it stuck at the inNetBuf.hasRemaining() place.
>>>>>>>
>>>>>>> Hope this information is useful.
>>>>>>>
>>>>>>> Thanks
>>>>>>> huican
>>>>>>>