[asterisk-dev] Can't connect to Jira with Safari OS/X

[Kevin P. Fleming]

On 07/08/2011 12:52 PM, Tilghman Lesher wrote:
> On Fri, Jul 8, 2011 at 11:23 AM, Kevin P. Fleming<kpfleming at digium.com>  wrote:
>> On 07/08/2011 10:51 AM, Olle E. Johansson wrote:
>>>
>>> 8 jul 2011 kl. 16.31 skrev Kevin P. Fleming:
>>>
>>>> On 07/08/2011 09:28 AM, Olle E. Johansson wrote:
>>>>>
>>>>> My Safari claims it can't open a secure connection to
>>>>> issues.asterisk.org
>>>>>
>>>>> Can someone at Digium forward this to IT staff? THe error message would
>>>>> not make sense to them, since it's localized into Swedish.
>>>>
>>>> The IT staff doesn't run the JIRA system, we here in Engineering do :-)
>>>>
>>>> In addition, we're aware of this problem, and it appears to be a bug in
>>>> Safari. The Apache proxy that sits in front of JIRA is configured to request
>>>> (but not require) an SSL client certificate, as we use that method for
>>>> providing privileged access to some JIRA accounts. It seems that Safari does
>>>> not know how to deal with this request properly, but other browsers handle
>>>> it just fine. It doesn't seem to be restricted to OS/X either... Safari on
>>>> Windows has the same problem.
>>>>
>>>> Unfortunately it's not possible to reconfigure Apache to avoid this
>>>> problem; we don't know what HTTP user-agent is in use until after the
>>>> SSL/TLS negotiations are completed.
>>>
>>> Check the SSLinsecurenegotiation parameter. I've just had a similar
>>> problem with an SSL client using a buggy OpenSSL. Maybe Safari suffers from
>>> the same.
>>>
>>> http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslinsecurerenegotiation
>>
>> That's re-negotiation; I'm pretty sure that this problem is happening during
>> the initial negotiation, not re-negotiation.
>
> No, that's re-negotiation.  The Apache server cannot know what URL was requested
> until after the SSL session is already established; therefore, it can
> only ask for a
> client certificate during renegotiation, once the /jira/ path is
> known.  Going to the base
> URL just confirms that it's renegotiation that is the problem.

Alright, good point. I'm not really willing to disable secure 
renegotiation though; there's a reason why those changes were made to 
the TLS protocol and implemented widely.

After some further testing, this has now been corrected, without 
enabling insecure renegotiation.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org