gRPC Security Series: Part 1

Introduction to gRPC

IBM PTC Security
4 min readSep 6, 2022

In this series of articles, we will be learning about a new remote procedure call framework, gRPC. It is a contemporary technology. However, based on our testing and research, we found possible vulnerable scenarios that we would be discussing during this series. This article introduces us to this new technology.

What is gRPC?

gRPC is a modern open-source high performance Remote Procedure Call (RPC) framework. It has been designed to run in any environment. It can efficiently connect services in and across data centers with support for:

Advantages of gRPC over other RPC Technology

The core problem that gRPC is trying to solve is communication delay. gRPC uses HTTP/2 as its transfer protocol and it offers some great features such as:

  • Binary framing
  • High performance and robust
  • Lighter to transport and safer to decode compared to other text-based protocols

Due to its binary nature, it is a great combination with protocol buffer.

HTTP/2 also compresses the headers using HPACK, which will reduce the overhead cost and improve the performance.

Multiplexing is possible in HTTP/2, which means the client and server can send multiple requests and responses in parallel over a single TCP connection. This will help reduce the latency and improve network utilisation.

And finally, HTTP/2 allows server-push, where with 1 single request from client, server can send back multiple responses. This is extremely valuable to reduce the round-trip latency between client and server in many cases, when server knows exactly what resources client will need and send them before they’re even requested.

gRPC vs REST

gRPC provides plenty of advantages. Unlike REST, it can make the most out of HTTP/2, using multiplexed streams and following the binary protocol. Plus, it offers performance benefits due to the Protobuf message structure, and let’s not forget the in-built code generation features which enable a multilingual environment. These reasons make gRPC a promising API architectural style for server-to-server communication.

Protobuf

The Protobuf file is one of the core components while defining the gRPC service. It basically stores the data and function contracts in the form of a proto file.

The Design goals for Protobuf emphasized simplicity and performance.

Both the client and server need to have the same proto file. The proto file acts as the intermediary contract for client to call any available functions from the server. Protobuf has its own mechanisms, unlike a usual REST API that just sends over strings of JSON as bytes.

These mechanisms allow the payload to be much smaller and enable faster performance.

A schema for a particular use of protocol buffers associates data types with field names, using integers to identify each field. The protocol buffer data contains only the numbers, not the field names, providing some bandwidth/storage savings compared with systems that include the field names in the data.

The “Point” message defines two mandatory data items, x and y. The data item label is optional. Each data item has a tag. The tag is defined after the equal sign. For example, x has the tag 1.

The “Line” and “Polyline” messages, which both use Point, demonstrate how composition works in Protocol Buffers. Polyline has a repeated field, which behaves like a vector.

This schema can subsequently be compiled for use by one or more programming languages. Google provides a compiler called protoc which can produce output for C++, Java or Python.

Other schema compilers are available from other sources to create language-dependent output for over 20 other languages.

Communication Pattern in gRPC

There are mainly 4 types of gRPC calls/communication patterns:

  1. Simple or Unary gRPC: Client sends 1 request to server and waits for server to respond. This is similar to any client/server call.
  2. Client-side streaming RPC: The client sends a series of messages to server and waits for the server to read and respond. The client streaming can be achieved by placing a “stream” keyword before request type in Protobuf file.
  3. Server-side streaming RPC: Here, the client sends a request to server, and expects a “stream” of responses and waits for it to complete the streams. The server streaming can be achieved by placing a “stream” keyword before response type.
  4. Bidirectional streaming RPC: Here, both client and server send sequence of messages using read-write stream. Both streams can read/write in which ever order they like making sure they operate independently. Bidirectional streaming can be achieved by placing the keyword “stream” before both request and response type.

Conclusion

In this article, we were familiarized with the basic concepts of gRPC and Protobuf file. In the next part, we will learn about how to access and interact with any gRPC application using different tools. Stay tuned for the same.

Article By:

Sruthi M

https://www.linkedin.com/in/sruthi-m-48600866/

Lead Penetration Tester

Johny B

https://www.linkedin.com/in/johny-bandlamudi-772607a3/

Penetration Tester

IBM PTC Penetration Testing and Security Services

--

--

IBM PTC Security

IBM PTC is a proficient internal Security Test Team responsible for vulnerability assessment & ethical hacking of web, mobile applications & infrastructure.