[7.7.1] SSLContext resignals X509 exceptions

> Martin,
>
> Indeed, the biggest hurdle here in this specific instance was
> resignaling of the original, because it sent me on a wild goose chase
> trying to handle RootNotTrusted, which appears at the top of the stack.
> If anything, I would recommend a quick mention of this somewhere in the
> security guide.
>
> Thanks!
>
> -Boris
>
> --
> DeepCove Labs Ltd.
> +1 (604) 689-0322
> 4th floor, 595 Howe Street
> Vancouver, British Columbia
> Canada V6C 2T5
> http://tinyurl.com/r7uw4
>
> PacNet Services (Europe) Ltd.
> +353 (0)61 714-360
> Shannon Airport House, SFZ
> County Clare, Ireland
> http://tinyurl.com/y952amr
>
> CONFIDENTIALITY NOTICE
>
> This email is intended only for the persons named in the message header.
> Unless otherwise indicated, it contains information that is private and
> confidential. If you have received it in error, please notify the sender
> and delete the entire message including any attachments.
>
> Thank you.
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: 08 December 2010 14:59
> To: Boris Popov, DeepCove Labs
> Cc: vwnc
> Subject: Re: [vwnc] [7.7.1] SSLContext resignals X509 exceptions
>
> That would be my fault. It's basically a general design question. If you
> write framework A that underneath uses framework B, is it better to let
> the B API leak through the A's API or is it better to cover it all up?
> After all often users don't need to be aware of the B underneath
> (although I won't deny that in this case users are painfully aware of
> X509 under SSL necessarily).
>
> In this particular case I swayed in the direction of covering it up,
> largely because the protocol actually defines SSL specific alerts (sent
> to the other side) for all these cases. SSLBadCertificate is an SSL
> alert for this situation that will be sent to the other side if you
> don't suppress it by resuming it. So with SSL you shouldn't be seeing
> any X.509 exceptions at the SSL API level (if I did a good enough job).
> I'm not saying that's the *right* way to do it, but I don't know that
> it's the *wrong* one either. However I certainly wouldn't want to raise
> both the X509 error and then the SSL error as well, and I feel that user
> should be aware that I'm about to send the SSL alert.
>
> As far as the general design question goes, I don't really know any
> objective argument showing that one way is better than the another. I
> suspect that it depends on case by case basis.
>
> Oh, one mistake that I do admit is that I shouldn't be #resignalling
> which makes the stack look like the replacement was raised from the
> initial context of the original exception. In retrospect I think that
> was the wrong choice, I should have just signalled the replacement from
> the handler at the SSL level. I don't need to restart the stack
> traversal from the bottom and it just looks confusing in the debugger.
>
> Cheers,
>
> Martin
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc 

> security guide.
>
> Thanks!
>
> -Boris
>
> --
> DeepCove Labs Ltd.
> +1 (604) 689-0322
> 4th floor, 595 Howe Street
> Vancouver, British Columbia
> Canada V6C 2T5
> http://tinyurl.com/r7uw4
>
> PacNet Services (Europe) Ltd.
> +353 (0)61 714-360
> Shannon Airport House, SFZ
> County Clare, Ireland
> http://tinyurl.com/y952amr
>
> CONFIDENTIALITY NOTICE
>
> This email is intended only for the persons named in the message

> and delete the entire message including any attachments.
>
> Thank you.
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: 08 December 2010 14:59
> To: Boris Popov, DeepCove Labs
> Cc: vwnc
> Subject: Re: [vwnc] [7.7.1] SSLContext resignals X509 exceptions
>
> That would be my fault. It's basically a general design question. If

> should be aware that I'm about to send the SSL alert.
>
> As far as the general design question goes, I don't really know any
> objective argument showing that one way is better than the another. I
> suspect that it depends on case by case basis.
>
> Oh, one mistake that I do admit is that I shouldn't be #resignalling
> which makes the stack look like the replacement was raised from the
> initial context of the original exception. In retrospect I think that
> was the wrong choice, I should have just signalled the replacement

> the handler at the SSL level. I don't need to restart the stack
> traversal from the bottom and it just looks confusing in the debugger.
>
> Cheers,
>
> Martin
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc 

> You'd have to add such comment to all places where translated exceptions
> are originally raised... I did do a search for RootNotTrusted and few
> other terms through documentation though and glanced through SSL
> Exceptions and Certificate Validation sections in the security guide.
> There are few mentions of exceptions being resumable, so perhaps that
> would be a good place to mention that exceptions might not be what they
> appear to be.
>
> Regards,
>
> -Boris
>
> --
> DeepCove Labs Ltd.
> +1 (604) 689-0322
> 4th floor, 595 Howe Street
> Vancouver, British Columbia
> Canada V6C 2T5
> http://tinyurl.com/r7uw4
>
> PacNet Services (Europe) Ltd.
> +353 (0)61 714-360
> Shannon Airport House, SFZ
> County Clare, Ireland
> http://tinyurl.com/y952amr
>
> CONFIDENTIALITY NOTICE
>
> This email is intended only for the persons named in the message header.
> Unless otherwise indicated, it contains information that is private and
> confidential. If you have received it in error, please notify the sender
> and delete the entire message including any attachments.
>
> Thank you.
>
>
> -----Original Message-----
> From: Bruce Boyer [mailto:[hidden email]]
> Sent: 08 December 2010 15:40
> To: Boris Popov, DeepCove Labs; [hidden email]
> Cc: vwnc
> Subject: Re: [vwnc] [7.7.1] SSLContext resignals X509 exceptions
>
> Would a code comment be more effective than the Security Guide?
> I'm just wondering where one would most likely look and find such
> information.
> Bruce
>
> ----- Original Message -----
> From: "Boris Popov, DeepCove Labs" <[hidden email]>
> To: <[hidden email]>
> Cc: "vwnc" <[hidden email]>
> Sent: Wednesday, December 08, 2010 7:03 AM
> Subject: Re: [vwnc] [7.7.1] SSLContext resignals X509 exceptions
>
>
> > Martin,
> >
> > Indeed, the biggest hurdle here in this specific instance was
> > resignaling of the original, because it sent me on a wild goose chase
> > trying to handle RootNotTrusted, which appears at the top of the
> stack.
> > If anything, I would recommend a quick mention of this somewhere in
> the
> > security guide.
> >
> > Thanks!
> >
> > -Boris
> >
> > --
> > DeepCove Labs Ltd.
> > +1 (604) 689-0322
> > 4th floor, 595 Howe Street
> > Vancouver, British Columbia
> > Canada V6C 2T5
> > http://tinyurl.com/r7uw4
> >
> > PacNet Services (Europe) Ltd.
> > +353 (0)61 714-360
> > Shannon Airport House, SFZ
> > County Clare, Ireland
> > http://tinyurl.com/y952amr
> >
> > CONFIDENTIALITY NOTICE
> >
> > This email is intended only for the persons named in the message
> header.
> > Unless otherwise indicated, it contains information that is private
> and
> > confidential. If you have received it in error, please notify the
> sender
> > and delete the entire message including any attachments.
> >
> > Thank you.
> >
> >
> > -----Original Message-----
> > From: [hidden email] [mailto:[hidden email]]
> > Sent: 08 December 2010 14:59
> > To: Boris Popov, DeepCove Labs
> > Cc: vwnc
> > Subject: Re: [vwnc] [7.7.1] SSLContext resignals X509 exceptions
> >
> > That would be my fault. It's basically a general design question. If
> you
> > write framework A that underneath uses framework B, is it better to
> let
> > the B API leak through the A's API or is it better to cover it all up?
> > After all often users don't need to be aware of the B underneath
> > (although I won't deny that in this case users are painfully aware of
> > X509 under SSL necessarily).
> >
> > In this particular case I swayed in the direction of covering it up,
> > largely because the protocol actually defines SSL specific alerts
> (sent
> > to the other side) for all these cases. SSLBadCertificate is an SSL
> > alert for this situation that will be sent to the other side if you
> > don't suppress it by resuming it. So with SSL you shouldn't be seeing
> > any X.509 exceptions at the SSL API level (if I did a good enough
> job).
> > I'm not saying that's the *right* way to do it, but I don't know that
> > it's the *wrong* one either. However I certainly wouldn't want to
> raise
> > both the X509 error and then the SSL error as well, and I feel that
> user
> > should be aware that I'm about to send the SSL alert.
> >
> > As far as the general design question goes, I don't really know any
> > objective argument showing that one way is better than the another. I
> > suspect that it depends on case by case basis.
> >
> > Oh, one mistake that I do admit is that I shouldn't be #resignalling
> > which makes the stack look like the replacement was raised from the
> > initial context of the original exception. In retrospect I think that
> > was the wrong choice, I should have just signalled the replacement
> from
> > the handler at the SSL level. I don't need to restart the stack
> > traversal from the bottom and it just looks confusing in the debugger.
> >
> > Cheers,
> >
> > Martin
> >
> > _______________________________________________
> > vwnc mailing list
> > [hidden email]
> > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc 
>

> I'm inclined to just fix the code rather than acknowledging the problem in documentation.
>
> "Boris Popov, DeepCove Labs"<[hidden email]> wrote:
> > You'd have to add such comment to all places where translated exceptions
> > are originally raised... I did do a search for RootNotTrusted and few
> > other terms through documentation though and glanced through SSL
> > Exceptions and Certificate Validation sections in the security guide.
> > There are few mentions of exceptions being resumable, so perhaps that
> > would be a good place to mention that exceptions might not be what they
> > appear to be.
> >
> > Regards,
> >
> > -Boris
> >
> > --
> > DeepCove Labs Ltd.
> > +1 (604) 689-0322
> > 4th floor, 595 Howe Street
> > Vancouver, British Columbia
> > Canada V6C 2T5
> > http://tinyurl.com/r7uw4
> >
> > PacNet Services (Europe) Ltd.
> > +353 (0)61 714-360
> > Shannon Airport House, SFZ
> > County Clare, Ireland
> > http://tinyurl.com/y952amr
> >
> > CONFIDENTIALITY NOTICE
> >
> > This email is intended only for the persons named in the message header.
> > Unless otherwise indicated, it contains information that is private and
> > confidential. If you have received it in error, please notify the sender
> > and delete the entire message including any attachments.
> >
> > Thank you.
> >
> >
> > -----Original Message-----
> > From: Bruce Boyer [mailto:[hidden email]]
> > Sent: 08 December 2010 15:40
> > To: Boris Popov, DeepCove Labs; [hidden email]
> > Cc: vwnc
> > Subject: Re: [vwnc] [7.7.1] SSLContext resignals X509 exceptions
> >
> > Would a code comment be more effective than the Security Guide?
> > I'm just wondering where one would most likely look and find such
> > information.
> > Bruce
> >
> > ----- Original Message -----
> > From: "Boris Popov, DeepCove Labs" <[hidden email]>
> > To: <[hidden email]>
> > Cc: "vwnc" <[hidden email]>
> > Sent: Wednesday, December 08, 2010 7:03 AM
> > Subject: Re: [vwnc] [7.7.1] SSLContext resignals X509 exceptions
> >
> >
> > > Martin,
> > >
> > > Indeed, the biggest hurdle here in this specific instance was
> > > resignaling of the original, because it sent me on a wild goose chase
> > > trying to handle RootNotTrusted, which appears at the top of the
> > stack.
> > > If anything, I would recommend a quick mention of this somewhere in
> > the
> > > security guide.
> > >
> > > Thanks!
> > >
> > > -Boris
> > >
> > > --
> > > DeepCove Labs Ltd.
> > > +1 (604) 689-0322
> > > 4th floor, 595 Howe Street
> > > Vancouver, British Columbia
> > > Canada V6C 2T5
> > > http://tinyurl.com/r7uw4
> > >
> > > PacNet Services (Europe) Ltd.
> > > +353 (0)61 714-360
> > > Shannon Airport House, SFZ
> > > County Clare, Ireland
> > > http://tinyurl.com/y952amr
> > >
> > > CONFIDENTIALITY NOTICE
> > >
> > > This email is intended only for the persons named in the message
> > header.
> > > Unless otherwise indicated, it contains information that is private
> > and
> > > confidential. If you have received it in error, please notify the
> > sender
> > > and delete the entire message including any attachments.
> > >
> > > Thank you.
> > >
> > >
> > > -----Original Message-----
> > > From: [hidden email] [mailto:[hidden email]]
> > > Sent: 08 December 2010 14:59
> > > To: Boris Popov, DeepCove Labs
> > > Cc: vwnc
> > > Subject: Re: [vwnc] [7.7.1] SSLContext resignals X509 exceptions
> > >
> > > That would be my fault. It's basically a general design question. If
> > you
> > > write framework A that underneath uses framework B, is it better to
> > let
> > > the B API leak through the A's API or is it better to cover it all up?
> > > After all often users don't need to be aware of the B underneath
> > > (although I won't deny that in this case users are painfully aware of
> > > X509 under SSL necessarily).
> > >
> > > In this particular case I swayed in the direction of covering it up,
> > > largely because the protocol actually defines SSL specific alerts
> > (sent
> > > to the other side) for all these cases. SSLBadCertificate is an SSL
> > > alert for this situation that will be sent to the other side if you
> > > don't suppress it by resuming it. So with SSL you shouldn't be seeing
> > > any X.509 exceptions at the SSL API level (if I did a good enough
> > job).
> > > I'm not saying that's the *right* way to do it, but I don't know that
> > > it's the *wrong* one either. However I certainly wouldn't want to
> > raise
> > > both the X509 error and then the SSL error as well, and I feel that
> > user
> > > should be aware that I'm about to send the SSL alert.
> > >
> > > As far as the general design question goes, I don't really know any
> > > objective argument showing that one way is better than the another. I
> > > suspect that it depends on case by case basis.
> > >
> > > Oh, one mistake that I do admit is that I shouldn't be #resignalling
> > > which makes the stack look like the replacement was raised from the
> > > initial context of the original exception. In retrospect I think that
> > > was the wrong choice, I should have just signalled the replacement
> > from
> > > the handler at the SSL level. I don't need to restart the stack
> > > traversal from the bottom and it just looks confusing in the debugger.
> > >
> > > Cheers,
> > >
> > > Martin
> > >
> > > _______________________________________________
> > > vwnc mailing list
> > > [hidden email]
> > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc 
> >

> > There's one glaringly obvious reason why I do indeed need to resignal the replacement, rather than raising it, and that is that the exception is meant to be resumable. And when it is resumed I need the code to continue from the point where the original was raised. So (now) I think that the code will have to stay as is, but we can certainly clarify the situation in comments and such.
>
> Presumably the other option would be to raise SSLBadCertificate, then
> resume the original, which would only happen if the SSLBadCertificate
> exception got resumed.  e.g.:
>
> ....]    on: Security.X509.BadCertificate, Security.X509.RootNotTrusted,
> Security.X509.BadCACertificate
>              do: [ :ex |
>                  sslEx := SSLBadCertificate replacementFor: ex.
>                  sslEx raise.
>                  ex resume]
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

> On 09/12/10 08:49, [hidden email] wrote:
> > Hm, that's a good point. So is this scheme better than resignaling ?
>
> It means that if you run some code that causes SSLBadCertificate to be
> raised, you get a debugger where you can see said exception being
> raised.  If you run the following two slightly contrived examples, in
> both cases you get a debugger on an SSLBadCertificate, but in the first
> case it's less than obvious that this is the case - it looks like you've
> still got the X509 exception.
>
> [Security.X509.Certificate new badCertificate] on:
> Security.X509.BadCertificate do: [:ex | ex resignalAs:
> (SSLBadCertificate replacementFor: ex)].
>
> [Security.X509.Certificate new badCertificate] on:
> Security.X509.BadCertificate do: [:ex | (SSLBadCertificate
> replacementFor: ex) raise.  ex resume].
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc