12:01 p.m.
Hi all,
No worries (yet), this is not about issues we have uncovered.
We have the opportunity however to have a team from the GEANT project
review the code of SaToSa. We already had them do a review of the
InAcademia service itself, now they can look at the code.
Their question is however, which areas would be of most interest to look
at, as just starting at line 1 is probably not a good idea ;)
Could you also express why these code areas are most sensitive?
* My initial guess would be the code that handles incoming OIDC and
SAML is most critical (so the backends). Including the bits that do
validation of these requests.
* Next the code that handles business logic of interpreting the
internal state and make the responses out of that
* Then the frontends
Does that make sense? Should we also include looking into the libraries
deeply?
In addition are you aware of additional reviews that were performed? If
so we would be really interested to learn about these.
Ofcause we will share the finding in a confidential way. By the way,
does idpy have some contingency rules about that already?
Thanks,
Niels
--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nl www.openconext.org
12:17 p.m.
Hi all,
On Wed, 4 Jul 2018 at 13:01, Niels van Dijk <niels.vandijk at surfnet.nl> wrote:
Hi all,
No worries (yet), this is not about issues we have uncovered.
We have the opportunity however to have a team from the GEANT project review the code of
SaToSa. We already had them do a review of the InAcademia service itself, now they can
look at the code.
I think that would be great! Is there a process for it? What is
checked; how; and what for?
Their question is however, which areas would be of
most interest to look at, as just starting at line 1 is probably not a good idea ;)
Could you also express why these code areas are most sensitive?
My initial guess would be the code that handles incoming OIDC and SAML is most critical
(so the backends). Including the bits that do validation of these requests.
Next the code that handles business logic of interpreting the internal state and make the
responses out of that
Then the frontends
Does that make sense? Should we also include looking into the libraries deeply?
SATOSA only connects frontends to backend (and vice versa), with some
intermediate logic that defines the internal representation of the
information it has collected, plus the metadata and configuration. The
"heavy lifting" is left to the libraries that actually implement the
standards. IMHO, the tricky bits are there; in the libs. So, my vote
would be yes, but lets start with the shell (SATOSA) and see if we can
move towards the core (libs) later.
In addition are you aware of additional reviews that
were performed? If so we would be really interested to learn about these.
Ofcause we will share the finding in a confidential way. By the way, does idpy have some
contingency rules about that already?
A document about how to report security vulnerabilities/issues and how
we should handle these reports is being formed.
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
4:08 p.m.
Hi
On 4 Jul 2018, at 12:17, Ivan Kanakarakis
<ivan.kanak at gmail.com> wrote:
On Wed, 4 Jul 2018 at 13:01, Niels van Dijk <niels.vandijk at surfnet.nl> wrote:
I’d also like to know the answers to Ivan’s questions.
When we’re talking about the SaToSa shell (front and backends) then anyone looking for
vulnerabilities must
be very good at the specific protocols used and have the mindset of a hacker.:-)
If that is the case here then I’m really, really looking forward to the result.
If not then I frankly question whether the work is useful.
My 2 c
— Roland
The higher up you go, the more mistakes you are allowed. Right at the top, if you make
enough of them, it's considered to be your style.
-Fred Astaire, dancer, actor, singer, musician, and choreographer (10 May 1899-1987)
No worries (yet), this is not about issues we have uncovered.
We have the opportunity however to have a team from the GEANT project review the code of
SaToSa. We already had them do a review of the InAcademia service itself, now they can
look at the code.
I think that would be great! Is there a process for it? What is
checked; how; and what for?
10:18 a.m.
Hi all,
Many thanks for the feedback!
In response to Rolands note below, I agree and at SURFconext we have had
a pretty hard time finding security testers that could indeed get into
the core of the saml/oidc implementation.
We ended up hiring some security experts from a German Uni in the end.
That said, I think it would be good to have a baseline for SaToSa.
Indeed as sugested, it needs to be clear what was tested and how. This
could then serve as the starting point for further more indepth analysis.
E.g. SURFnet might actually be willing to fund the latter, should we get
a green light to bring our SaToSa based services in production. We are
required to to perform a security audit of the software we use before we
bring stuff into production.
Cheers,
Niels
On 04-07-18 16:08, Roland Hedberg wrote:
Hi
--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nl www.openconext.org
On 4 Jul 2018, at 12:17, Ivan Kanakarakis
<ivan.kanak at gmail.com
<mailto:ivan.kanak at gmail.com>> wrote:
On Wed, 4 Jul 2018 at 13:01, Niels van Dijk <niels.vandijk at surfnet.nl
<mailto:niels.vandijk at surfnet.nl>> wrote:
I’d also like to know the answers to Ivan’s questions.
When we’re talking about the SaToSa shell (front and backends) then
anyone looking for vulnerabilities must
be very good at the specific protocols used and have the mindset of a
hacker.:-)
If that is the case here then I’m really, really looking forward to
the result.
If not then I frankly question whether the work is useful.
My 2 c
— Roland
The higher up you go, the more mistakes you are allowed. Right at the
top, if you make enough of them, it's considered to be your style.
-Fred Astaire, dancer, actor, singer, musician, and choreographer (10
May 1899-1987)
No worries (yet), this is not about issues we have uncovered.
We have the opportunity however to have a team from the GEANT
project review the code of SaToSa. We already had them do a review
of the InAcademia service itself, now they can look at the code.
I think that would be great! Is there a process for it? What is
checked; how; and what for?
2384
days inactive
2386
days old
3 comments
3 participants
participants (3)
-
ivan.kanak＠gmail.com -
niels.vandijk＠surfnet.nl -
roland＠catalogix.se