Re: [Pan-devel] at b2069b3 now -- I think I figured-out one little thing (Re: ANN: SSL Support))

[Heinrich Mueller]

Am 11.11.2011 23:35, schrieb SciFi:
> Another thing…
>
> On Fri, 11 Nov 2011 22:17:03 +0000, SciFi wrote:
> > Hi,
> >
> > (I thought I would check the list while fixing supper
> >   and before laying down)
> >
> > On Fri, 11 Nov 2011 22:32:57 +0100, Heinrich Mueller wrote:
> > > Am 11.11.2011 21:03, schrieb SciFi:
> > > > It might be that the pem file needs to match
> > > > the "officially registered" names for the certs.
> > > > And for Pan keep track of that gook, somehow.   ;)
> > > >
> > > > (...)
> > > >
> > > > Does this make any sort of sense at all?
> > > > (honestly asking)
> > > Yes, my code as of yet reads the pem files and
> > > matches them with the filename. Perhaps I'll just a map-based
> > > approach with a file telling which certificate belongs to
> > > which server and i just name them after the md5 checksum or
> > > something.
> > > That was just the simplest thing for me, because normally the
> > > user doesn't rename his certificates as pan stores them automatically.
> > > I think I'll implement an option in the servers.xml file.
> > >
> > > Cheers.
> > Ah.
> > So.
> > I guess the thing to remember is something like this:
> > Us mere mortals wouldn't normally need to worry about
> > matching these things together properly.  We would
> > expect things to "just work" by the code doing
> > whatever "magic" is required.   ;)
> >
> > For us geeks trying to iron-out this present anomaly,
> > I still cannot find what the "proper name" should be
> > for the gn and gmane certs/pems.
> >
> > However, I suppose discovering the aw name was
> > more of an "accident" it seems to work that way.  ;)
> >
> > I then suppose the OpenSSL APIs will have something
> > to offer for the app to keep-track of these certs?
> > (Other software, that support SSL, seem to handle
> >   all this tracking automatically.  The app only
> >   needs to know whether to use SSL-mode or not.)
> >
> > Thanks again.
> Another thought:
> I believe most apps that support SSL
> will keep the cert(s)&  details in RAM
> for the duration of the session(s).
> The app won't record anything SSL-related to disk
> nor will the app "ask" to "accept" the cert.
> That means there will be "handshaking"
> once a session is (re)started
> every time
> yes every time.
> This might also necessarily change the
> encryption keys etc. for each session/thread
> but I would think it'd be "safer" this way.
>
> (sometimes a bit of good food
>   helps my noggin do some thinkin'<g>)
>
> (but what do I really know about this stuff)
>
> (I will probably go lay down now)
>
>
>
>
> _______________________________________________
> Pan-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/pan-devel
You're partly right: SSL stores the encryption keys/certificates etc.
in RAM, but at initialization it gets its certificates _also_ by parsing
files on the disk. SSL trusts those and never "untrusts" them, so
to speak, as long as the SSL context or certificate store exists.
That means I only have to init the certificates once at startup, and
what seemed most feasible not to annoy the user was to do this
with a disk-based approach. I also chmod the files so only the user using
pan can actually read them.