[Bug]: SSL Verification Causes Connection Timeouts in Production

[iqbalhasandev]

What happened?

The Laravel Textify package is experiencing connection timeout errors in production environments due to SSL verification being enabled by default. This causes cURL timeout errors when communicating with SMS provider APIs, particularly affecting the ReveSmsProvider.

How to reproduce the bug

🔍 Error Details

Error Message:

cURL error 28: Connection timed out after 30002 milliseconds (see https://curl.haxx.se/libcurl/c/libcurl-errors.html)

Full Error Response:

{
    "provider": "revesms",
    "to": "01977343017",
    "error": "cURL error 28: Connection timed out after 30002 milliseconds (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://smpp.revesms.com:7790/sendtext?apikey=...",
    "trace": "#0 /vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php(205): GuzzleHttp\\Handler\\CurlFactory::createRejection()..."
}

🔄 Steps to Reproduce

1. Configure Laravel Textify with ReveSmsProvider in production environment
2. Set verify_ssl=false in configuration (this should disable SSL verification but doesn't work consistently)
3. Attempt to send an SMS message
4. Observe connection timeout error

🎯 Expected Behavior

• SSL verification should be disabled by default to prevent connection issues in production
• When verify_ssl=false is configured, all HTTP requests should respect this setting
• Users should be able to opt-in to SSL verification if needed for security

🚫 Actual Behavior

• SSL verification defaults to true across all providers
• Even when verify_ssl=false is configured, some HTTP clients still use SSL verification
• Connection timeouts occur in production environments with SSL certificate issues

🛠️ Root Cause Analysis

The issue stems from multiple places in the codebase where SSL verification defaults to true:

1. BaseProvider.php: Default Guzzle configuration uses $this->config['verify_ssl'] ?? true
2. ReveSmsProvider.php: The getBalance() method creates a separate HTTP client that ignores the SSL configuration
3. All Bangladeshi Providers: Default to SSL verification enabled

---

Priority: High
Severity: Critical (blocks production usage)
Impact: Multiple providers affected, production deployments failing

Package Version

v1.1.1

PHP Version

8.4

Laravel Version

12

Which operating systems does this happen with?

Linux

Notes

🔧 Proposed Solution

1. Change default SSL verification to false across all providers
2. Ensure all HTTP clients respect the SSL configuration
3. Allow users to opt-in to SSL verification by setting verify_ssl=true
4. Update documentation to reflect the change

📋 Files That Need Changes

• src/Providers/BaseProvider.php
• src/Providers/Bangladeshi/ReveSmsProvider.php
• src/Providers/Bangladeshi/AlphaSmsProvider.php
• src/Providers/Bangladeshi/DhorolaSmsProvider.php
• src/Providers/Bangladeshi/EsmsProvider.php
• src/Providers/Bangladeshi/MimSmsProvider.php
• config/textify.php

🧪 Test Cases Needed

test('ssl verification defaults to false for all providers', function () {
    $providers = [
        'revesms', 'alphasms', 'dhorolasms', 'esms', 'mimsms'
    ];
    
    foreach ($providers as $provider) {
        $instance = textify()->provider($provider);
        $reflection = new ReflectionClass($instance);
        $httpClient = $reflection->getProperty('httpClient');
        $httpClient->setAccessible(true);
        $client = $httpClient->getValue($instance);
        
        $config = $client->getConfig();
        expect($config['verify'])->toBeFalse();
    }
});

test('users can explicitly enable ssl verification', function () {
    config(['textify.providers.revesms.verify_ssl' => true]);
    
    $provider = textify()->provider('revesms');
    $reflection = new ReflectionClass($provider);
    $httpClient = $reflection->getProperty('httpClient');
    $httpClient->setAccessible(true);
    $client = $httpClient->getValue($provider);
    
    $config = $client->getConfig();
    expect($config['verify'])->toBeTrue();
});

📚 Additional Context

This is a breaking change in terms of security defaults, but it's necessary to ensure the package works reliably in production environments. Most SMS provider APIs don't require strict SSL verification, and this change aligns with common practices in similar packages.