Re: RPG SSL Sockets

Hi Chris,

My service program approach is quite a bit different from what you
describe. I never let my caller get to the actual descriptor... I
encapsulate all the stuff like selects, reads, writes, etc into the service
program.

This way, I can do stuff under the covers like buffering the data (since I
never have to worry about the caller doing send/recv/read/write directly, I
can buffer data to improve speeds). The caller can do either SSL or plain
text without having to call a separate set of APIs, because the raw
implementation is not available to it, etc.

This, of course, makes the service program fairly complex -- but the
applications are pretty simple, and can focus on the application's logic
rather than on network logic.

Regarding client certificates: Keep in mind that 99% of the SSL
connections made do not use client certificates. So when you're talking
about this, you're talking about the "normal" way of doing SSL.

The purpose of certificates is to ensure that your data is sent to the
entity that you THINK it's being sent to. If you are a shopper buying
things from Acme.com's web site, and you're about to type a credit card
number into the page, it's simply not good enough to know that the data
will be encrypted. You also have to know that you're REALLY at Acme's web
site. It's easy for Joe Hacker to grab Acme's logo and put up a web site
that looks like Acme.com. You don't want to encrypt your CC, and send it
securely so that only Joe Hacker can decrypt it -- what good is that? The
certificate tells you that it's really Acme, and not Joe Hacker.

On the other hand, it's not usually necessary for Acme to know that you're
really Chris Bipes. If you have Chris's userid, password and credit card,
that's good enough for Acme. Expecting every consumer to register for
their own SSL certificate just to buy goods would not work.

So, server-side certificates are required. Client side are not for most
applications.

If you do not plan to use client-side ceritificates, then you can create
the application without GSK_OS400_APPLICATION_ID if you prefer. The
application ID associates your program with settings in the Digital
Certificate Manager -- but if you'd rather just always use default
settings, and don't want to have to configure things in the DCM, you can
replace the GSK_OS400_APPLICATION_ID code with this, instead:

rc = gsk_attribute_set_buffer( SslEnv
: GSK_KEYRING_FILE
: '*SYSTEM'
: 0);

That tells it to use the default settings for the *SYSTEM certificate
store instead of setting up an application ID, et al.

Clear as mud?


On 11/5/2014 4:32 PM, Chris Bipes wrote:

Thank you Scott. Believe it or not I found the same question I asked you
a couple of years ago. (Well further back than that but I don't want to
date myself.)

I have downloaded your SSLClient and SSLSever code from iProDeveloper and
have two systems talking.

I was looking a building a service program that I can do something like:
CrtSSLclientConnection
URL
Port

and return the descriptor to do the selects, reads, and writes to.

Make the application simple but the service program do the work.

Now if I do not specify a client certificate, I can still get a secure
connection to the server, but don't identify myself. Is this a true
statement?

The client does not have to have the GSK_OS400_Application_ID set or does
it? I know a server does to present the correct SSL certificate but does
the client? This is where I am fuzzy brained.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.