Skip to Main Content
IBM Power Ideas Portal


This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Not under consideration
Workspace IBM i
Categories Networking
Created by Guest
Created on Sep 11, 2021

SSL enable give/takedescriptor API's

The give/takedescriptor API's allow one to exchange the socket between a listener (main) program and a submitted client job.

This however only works for non-SSL connections which makes it impossible to use the concept for accepting multiple simultaneous clients.

Please provide a method for transferring the SSL state of the socket to a client job.


Use Case:

The give/takedescriptor API's allow one to exchange the socket between a listener (main) program and a submitted client job.

This however only works for non-SSL connections which makes it impossible to use the concept for accepting multiple simultaneous clients.

Please provide a method for transferring the SSL state of the socket to a client job.


Idea priority Urgent
  • Guest
    Reply
    |
    Dec 6, 2021

    We are happy to see you were able to split the secure handshake processing into the 2nd process, by passing the connection first, and then securing it in the 2nd process. Since there is an alternate working design and IBM does not intend to provide a give/takedescriptor solution, the request is being closed.

  • Guest
    Reply
    |
    Oct 14, 2021

    The CEAC has reviewed this requirement and recommends that IBM view this as a MEDIUM priority requirement that should be addressed.

    Background: The COMMON Europe Advisory Council (CEAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CEAC has a crucial role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community and has therefore reviewed your RFE.

    To find out how CEAC help to shape the future of IBM i, see CEAC @ ibm.biz/BdYSYj and the article "The Five Hottest IBM i RFEs Of The Quarter" at ibm.biz/BdYSZT

    Therese Eaton – CEAC Program Manager, IBM

  • Guest
    Reply
    |
    Oct 12, 2021

    I can confirm that the "split the accept/upgrade process" works. The SSL logic is now transferred from the "listener" job to the submitted "client" job.

    A side note is however that the "listener" job is not aware that the "client" job might fail due to an incorrect SSL negotiation (so far I don't know if there are other implications of this split logic).

  • Guest
    Reply
    |
    Oct 7, 2021

    I'm currently evaluating the "split the accept/upgrade process" but still have a few issues.

    I'll report back in this RFE once I have more information if this is a viable solution.

  • Guest
    Reply
    |
    Oct 6, 2021

    Thank you for providing the additional information. IBM understands the requirement and will evaluate it as part of the plan process. A response will be provided after evaluation is complete.

  • Guest
    Reply
    |
    Sep 21, 2021

    The CAAC has reviewed this requirement and recommends that IBM view this as a medium priority requirement that should be addressed. Although there are viable work-arounds, this request is one of the more worthwhile to implement.

    Background: The COMMON Americas Advisory Council (CAAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CAAC has a key role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community, and has therefore reviewed your RFE.

    For more information about CAAC, see www.common.org/caac

    Nancy Uthke-Schmucki - CAAC Program Manager

  • Guest
    Reply
    |
    Sep 21, 2021

    Hi,

    The application originates from a "single" connection where the accepted socket was upgraded to an SSL socket and being used to communicate with the client in SSL mode. By upgrading the program to a "multiple client" version the socket logic was kept together, after which the socket was passed to the client. I could try to split the accept/upgrade process between the listener program and the actual server program as you seem to suggest.

    The new process runs under the same userprofile by default however this isn't a strict requirement (however authority shouldn't be a problem). If the same userprofile is however a requirement, it should be no problem to respect this requirement.

    Yes, the GSKit API's are used, ie. gsk_secure_soc_open, gsk_attribute_set_numeric_value, gsk_secure_soc_init.

  • Guest
    Reply
    |
    Sep 20, 2021

    Hello Paul,
    Thank you for taking the time to submit this request. We would like to get some more information to further understand and assess your Request for Enhancement.

    Why does the application server pass the secure connection between processes? Can the server process accept the new TCP connection and pass the connection to have the client process establish the secure connection rather than pass the connection after the secure session is established? Does the new process run under the same user profile as the server process listening for connections or what authority does the profile have for the giving and taking processes? Does your application use the GSKit APIs to establish the secure connection?