cpw.ivan: d849dc2a: This is kind of controversial, but appar...

[Paul Aurich]

On 2010-11-01 11:51, Mark Doliner wrote:
> On Sat, Oct 30, 2010 at 5:36 PM, Paul Aurich <paul at darkrain42.org> wrote:
>> On 2010-10-30 14:16, ivan.komarov at soc.pidgin.im wrote:
>>> This is kind of controversial, but apparently not having tlsCertName
>>> in the startOSCARSession response is normal and indicates we
>>> shouldn't use SSL for connecting to BOS even if we requested
>>> SSL in account settings.
>>
>> I would prefer that we error the connection in this situation (with a
>> useful error message), not just log an error message to the Debug Window.
>>
>> Either that or move to a "Don't use TLS/Use TLS if available/Require
>> TLS" dropdown.
> 
> Authentication will always happen over https in either case, right?
> We're only concerned about silent fallback to http for buddy list,
> IMs, etc?

That's my understanding of the code changes.  (My personal use case, for
what it's worth, is when I'm at a coffee shop or somewhere else with
terrible wireless security, either I want c2s to be encrypted, or I want
a connection error)

>  If AOL's https servers were more reliable I think we could
> get away with a simple "Require encryption" checkbox.  Unfortunately,
> I feel like it's probably a good idea for us to give users the option
> to disable https entirely.

I agree with both points.

> What if we change the current "Use SSL" checkbox to a dropdown box
> with these options:
>     "Require encryption"
>     "Use encryption if available"
>     "Don't use encryption"
> Should be very similar to XMPP's dropdown in appearance.  Maybe we
> should add a note that says, "your password will always be encrypted,
> regardless of this setting"?  Mouse-over tooltip maybe?  And I'd vote
> that the default setting be "use encryption if available."

Again, all of that WFM.

Ivan and I were discussing this off-list (I think he mentioned in
devel at cpi that he forgot to Reply-All.  Ivan, feel free to bring that
back on list if you want), and he pointed out that
purple_parse_auth_resp needs logic to handle those different options
(and generate a less-than-friendly connection error if a new SNAC server
connection doesn't use TLS when we requested it to and the option is set
to Require Encryption)

> 
> --Mark
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20101101/0640134d/attachment.sig>